WEBVTT
00:00:00.000 --> 00:00:22.180
36C3 preroll music
00:00:22.180 --> 00:00:28.540
Herald: So, have you ever wondered how to
almost perfectly fake an email? Then you
00:00:28.540 --> 00:00:33.369
might be actually in the right talk here.
We have our next speaker. Andrew, who is
00:00:33.369 --> 00:00:41.180
currently working for the National CERT of
Latvia as a security researcher. And he's
00:00:41.180 --> 00:00:50.120
going to talk about e-mail counterfeiting
and strategies for modern anti-spoofing.
00:00:50.120 --> 00:00:53.356
Stage is yours.
00:00:53.356 --> 00:01:04.460
Applause
00:01:04.460 --> 00:01:14.490
Andrew: So. Greetings. I'm Andrew and I
work for Latvian National CERT. One of our
00:01:14.490 --> 00:01:21.440
current goals is improving the state of
email security in our country and which we
00:01:21.440 --> 00:01:26.400
mostly do through raising awareness about
this issue and communicating best
00:01:26.400 --> 00:01:30.770
practices. And of course we are not the
only organization that is doing that.
00:01:30.770 --> 00:01:34.420
There are many more CERTs in other
countries and there are various
00:01:34.420 --> 00:01:39.299
nongovernmental organizations that are
doing the same. And commercial entities.
00:01:39.299 --> 00:01:46.060
However, so far, frankly speaking, our
collective progress has been quite
00:01:46.060 --> 00:01:54.100
underwhelming. So for example, here is the
one stat which is the usage of one
00:01:54.100 --> 00:01:59.770
specific technology, DMARC, which as you
will learn in this talk, is quite
00:01:59.770 --> 00:02:06.770
important and I hope that everyone will
start using it. So on the left. There are
00:02:06.770 --> 00:02:11.060
twenty thousand domains across all the
world which are important domains for
00:02:11.060 --> 00:02:15.880
important organizations that truly should
know better. And on the right side we see
00:02:15.880 --> 00:02:24.799
the top 50, top 500 EU retailer domains
and across both of these groups two thirds
00:02:24.799 --> 00:02:29.799
haven't even configured DMARC yet. And out
of those that have configured majority
00:02:29.799 --> 00:02:36.350
hasn't enabled strict policy yet. So if
there is just one key takeaway from this
00:02:36.350 --> 00:02:41.459
talk, I hope that it will be that everyone
should start using DMARC. It is important
00:02:41.459 --> 00:02:49.120
to use it even for domains that are not
supposed to send email. So, one
00:02:49.120 --> 00:02:56.760
explanation for these low adoption rates,
I think, is that, there are seemingly too
00:02:56.760 --> 00:03:04.310
many competing technologies. This is the
contents for my talk. And I really tried
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
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
00:03:18.739 --> 00:03:25.570
whole name for them. But still, they are
all important. And of course, this problem
00:03:25.570 --> 00:03:28.949
that there are too many buzzwords, too
many technologies, and it's not clear
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
00:03:34.590 --> 00:03:39.760
across the industry and, ah, security
industry, i think by now we have found at
00:03:39.760 --> 00:03:47.880
least one way to solve it. And it is
penetration testing. So when the
00:03:47.880 --> 00:03:53.370
penetration test has been run properly and
the results have been published, then we
00:03:53.370 --> 00:03:58.190
can start talking. We can shift the
conversation from talking about whether
00:03:58.190 --> 00:04:03.510
your organization prefers technology A or
technology B we can instead start talking
00:04:03.510 --> 00:04:09.620
about the questions that really matter,
such like: Is it possible for someone for
00:04:09.620 --> 00:04:15.310
some third party to spoof your
organization's e-mails and to send such
00:04:15.310 --> 00:04:20.989
e-mails to your, for example, customers or
your partners or to media organizations in
00:04:20.989 --> 00:04:24.970
such a way that they will think that the
emails really came from within your
00:04:24.970 --> 00:04:31.810
organization? So that's why penetration
testers are the key audience for this
00:04:31.810 --> 00:04:36.020
talk. However, I hope that any blue
teamers in the audience also will find
00:04:36.020 --> 00:04:40.650
this talking interesting. I'm sure that
you already know all the basics about the
00:04:40.650 --> 00:04:43.620
email and about these technologies, but
looking at the problem from the different
00:04:43.620 --> 00:04:50.440
side from attacker's perspective sometimes
can really put things into perspective. It
00:04:50.440 --> 00:04:54.819
can help for you understand what you
should focus on when protecting your
00:04:54.819 --> 00:05:01.009
environment. And finally, the SMTP
protocol. The technology that runs
00:05:01.009 --> 00:05:07.720
underneath our e-mail conversations is
actually relatively easy to understand.
00:05:07.720 --> 00:05:14.061
And so. And also the lessons learned from
all of this journey from SMTP, how it
00:05:14.061 --> 00:05:20.979
became and how it's possible to spoof it
and all the technologies that are trying
00:05:20.979 --> 00:05:27.530
to prevent spoofing. I think it's a
interesting case study and it should be
00:05:27.530 --> 00:05:33.719
interesting to follow even for people who
are new to e-mail. Um, finally. Threat
00:05:33.719 --> 00:05:41.400
landscape. So email security is quite a
wide topic. And so today I will only focus
00:05:41.400 --> 00:05:47.650
on one small part of it, which is
successful spoofing of e-mails. Tampering
00:05:47.650 --> 00:05:54.689
attacks. And I know that many, penetration
testers already, incorporate some part of
00:05:54.689 --> 00:06:01.250
phishing or spear phishing, emulation
into their engagements and. But as far as
00:06:01.250 --> 00:06:07.070
I know, they mostly do it from the, social
engineering perspective using such tools
00:06:07.070 --> 00:06:13.090
as a social engineering toolkit, for
example. And it's, uh, I don't want to
00:06:13.090 --> 00:06:16.949
argue, though, that it's important to do
that and to demonstrate to the customer
00:06:16.949 --> 00:06:23.860
that what risks are in regards with social
engineering. However, I think you're doing
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
00:06:28.099 --> 00:06:32.650
email perspective, because from the
customers, from managers perspective that
00:06:32.650 --> 00:06:38.870
are reading your reports, if they only
mention social engineering attacks, then
00:06:38.870 --> 00:06:44.650
the logical conclusion is, that the best
way to mitigate these threats is by
00:06:44.650 --> 00:06:51.590
educating your personnel, especially those
that are least technical, as you will see
00:06:51.590 --> 00:06:55.379
in this talk. There are quite a lot of
attacks and many organizations are
00:06:55.379 --> 00:07:00.230
susceptible to them, which are much better
than that. And no amount of user education
00:07:00.230 --> 00:07:03.889
will help here because we can't expect
users to check headers, for example,
00:07:03.889 --> 00:07:10.699
manually. So we actually need to improve
our e-mail infrastructure. No way around
00:07:10.699 --> 00:07:17.009
it. And finally, before we move on to
actual technical stuff, there's a little
00:07:17.009 --> 00:07:21.889
secret, which I think might help people
that are not working in the email industry
00:07:21.889 --> 00:07:28.159
understand why we have such problems and
is that, for email admins historically,
00:07:28.159 --> 00:07:38.040
um, they value availability of their
system and reliable reliability much more
00:07:38.040 --> 00:07:44.680
than security. And that's because that's
not an ideological decision. It's a very
00:07:44.680 --> 00:07:50.469
pragmatic one. So, for example, if you are
an e-mail an email admin in an
00:07:50.469 --> 00:07:56.090
organization and some of your customers
stop receiving invoices, your management
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
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
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,
00:08:13.509 --> 00:08:20.449
other example, if you, if some of your,
some of your employees can't receive
00:08:20.449 --> 00:08:24.969
e-mail soon enough, for example, to
restore the password or to verify the
00:08:24.969 --> 00:08:30.190
email or to use multi factor
authentication token and they can't log
00:08:30.190 --> 00:08:33.969
into some important systems again, they
will find you on though you will need to
00:08:33.969 --> 00:08:39.539
solve that. But if your system is has some
security vulnerabilities, if it's assessed
00:08:39.539 --> 00:08:45.540
susceptible to spoofing attacks and so on,
then not users, no management will
00:08:45.540 --> 00:08:50.670
normally notice it. You might not not
notice it, but you are. You have this
00:08:50.670 --> 00:08:55.930
vulnerability. So that's why obviously
penetration testers are important. Okay.
00:08:55.930 --> 00:09:01.250
Now we can finally start talking about the
technical stuff. So and we will start with
00:09:01.250 --> 00:09:07.190
the short introduction to SMTP protocol.
SMTP is the protocol that underlies all
00:09:07.190 --> 00:09:12.360
email communications and it's actually
pretty easy to follow. So here's a data
00:09:12.360 --> 00:09:18.370
flow of what's happening when one person
sends e-mail to another person. For
00:09:18.370 --> 00:09:21.269
example Alice is sending to Bob and
they're using different they are working
00:09:21.269 --> 00:09:24.970
for different companies. They use
different domains. So what's happening
00:09:24.970 --> 00:09:29.290
here is that both of them would say use
email clients such as Outlook or
00:09:29.290 --> 00:09:34.580
Thunderbird. And Alice is sending email.
It's going through this protocol SMTP to
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.
00:09:41.740 --> 00:09:44.790
Usually organizations will have two types
of servers, one for incoming transactions
00:09:44.790 --> 00:09:48.680
and one for outgoing and for smaller
organizations it might be one server, but
00:09:48.680 --> 00:09:52.470
again, it's important for penetration
tester to think of this as different
00:09:52.470 --> 00:09:56.680
systems because they will have even if
it's physically one machine, it will have
00:09:56.680 --> 00:10:00.620
different configuration for outgoing mail
and for incoming mail. So as a penetration
00:10:00.620 --> 00:10:04.899
tester you need to check both of them.
Okay. Now, when Alice's server tries to
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
00:10:11.940 --> 00:10:16.480
somehow automatically find what is the
other server to send the email and it is
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
00:10:25.220 --> 00:10:29.680
something that is maintained by Bob's
organization. So Bob's organization, if
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
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
00:10:38.830 --> 00:10:44.290
to Bob's server. And Alice's outgoing
server knowing Bob's incoming server
00:10:44.290 --> 00:10:50.670
address can communicate to that. And then
later, Bob, will receive its e-mail. So
00:10:50.670 --> 00:10:54.970
the part that we as penetration testers
will be trying to breach is actually
00:10:54.970 --> 00:10:59.839
between Alice's server and between Bob
Server. And then we need to think about
00:10:59.839 --> 00:11:03.511
the second example, which is the opposite
way. And you might think that it's a
00:11:03.511 --> 00:11:07.110
pointless example because we are just
basically changing the direction of
00:11:07.110 --> 00:11:11.449
traffic. But the important part here is
for us as penetration testers to
00:11:11.449 --> 00:11:17.220
understand that our client only controls
part of this transaction. If our client,
00:11:17.220 --> 00:11:20.760
let's say, for the rest of this
presentation is Alice or Alice's
00:11:20.760 --> 00:11:26.750
organization, then in the second example
when we are sending mail from Bob to
00:11:26.750 --> 00:11:34.600
Alice, then we'll be sending emails only.
Basically, part of this transaction will
00:11:34.600 --> 00:11:40.980
go through Alice's servers. In the first
example, if we were sending email from
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
00:11:45.940 --> 00:11:51.600
return to that a bit later. And finally,
there is a third example which looks
00:11:51.600 --> 00:11:56.260
similar, but not quite. And that's if
Alice is communicating. Alice is our
00:11:56.260 --> 00:12:01.070
customer. And if she is communicating with
her coworkers, which are using the same
00:12:01.070 --> 00:12:04.320
organization, same e-mail server, same
domain. In that example, again, there will
00:12:04.320 --> 00:12:09.000
be to at least logically two email
servers, outgoing server and incoming
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
00:12:15.850 --> 00:12:20.149
familiar with e-mail, you can. It's
just interesting to try to think which of
00:12:20.149 --> 00:12:27.740
these scenarios, three scenarios, which of
them are easier to protect? And a bit
00:12:27.740 --> 00:12:31.769
later we will see how it's actually
happening. Okay. And then we need to look
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
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
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
00:12:48.029 --> 00:12:54.410
open telnet connection to the right server
and you can try writing down the commands
00:12:54.410 --> 00:12:58.680
just with your hands. So you can try
mangling something or modifying or trying
00:12:58.680 --> 00:13:05.149
different, different, different types and
see in real time how it was going on. So
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
00:13:11.209 --> 00:13:14.720
all, there comes SMTP envelope, which
basically you connect the server, say
00:13:14.720 --> 00:13:22.070
hello, then you say what. Specify the
sender of email and recipient. "mail from"
00:13:22.070 --> 00:13:26.980
is sender. Recipient is Bob, for example.
And then the second part starts with data
00:13:26.980 --> 00:13:32.160
and ends with quit. And that's the part
which is called Content/Message. So just
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
00:13:35.480 --> 00:13:38.029
standard, which is not that important for
penetration testers but if you want to
00:13:38.029 --> 00:13:43.890
look into details and it might be
important. And this internal message,
00:13:43.890 --> 00:13:49.069
which is called either Content or SMTP
message, it again, it contains two parts.
00:13:49.069 --> 00:13:53.300
One is headers and another is body. And I
think some people might not be familiar
00:13:53.300 --> 00:13:57.569
with email, but probably everyone is
familiar in this audience with HTTP and
00:13:57.569 --> 00:14:02.600
this looks quite, quite the same. So easy
to understand. But the interesting part
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.
00:14:08.550 --> 00:14:14.350
Right. For example, Alice's is specified
on the second line "mail from". And then
00:14:14.350 --> 00:14:19.709
we have the same address. alice @ her
organization in "From" header. The red
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
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
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
00:14:39.139 --> 00:14:44.980
sort of postcard. So on a postcard there
is someone who has sent it. The sender.
00:14:44.980 --> 00:14:48.980
There is the recipient. That's usually me.
I'm receiving. And then there's some
00:14:48.980 --> 00:14:53.569
message. So at least that's how I
perceived it before I learned a bit more
00:14:53.569 --> 00:14:58.670
about it. But email admins and the
standard bodies, they see this situation
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
00:15:04.610 --> 00:15:10.480
the envelope then there is this message or
a postcard maybe. So you have two
00:15:10.480 --> 00:15:15.350
addresses in this scenario. You specified
the address from and to whom you are
00:15:15.350 --> 00:15:20.730
sending the envelope, which is the part
that post office, for example, will look.
00:15:20.730 --> 00:15:24.589
But post office won't look generally
inside your envelope and inside the
00:15:24.589 --> 00:15:28.880
envelope there is another message, and
that is the internal message is actually
00:15:28.880 --> 00:15:33.889
meant for a recipient. So actually, you
could do even more and you could even put
00:15:33.889 --> 00:15:40.060
the whole envelope with the message of the
postcard inside another envelope. And this
00:15:40.060 --> 00:15:46.500
sounds crazy to me as a regular person,
but actually e-mail allows that. And in
00:15:46.500 --> 00:15:50.029
the RFC the standard document, there are
some examples why that would be necessary.
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
00:15:56.939 --> 00:16:03.009
result, it is the here in this first
example, we see that we generally we are
00:16:03.009 --> 00:16:07.940
specifying the same address twice. But as
a penetration tester the question that
00:16:07.940 --> 00:16:12.170
we should be asking is: So is that
required, actually? Is that always true or
00:16:12.170 --> 00:16:17.120
is it just like a wishful thinking? And
it's actually wishful thinking. So
00:16:17.120 --> 00:16:20.870
standards specifically do not say that you
should be specifying the same address for
00:16:20.870 --> 00:16:27.140
recipient or for "From" from the sender on
the envelope and inside a message. So you
00:16:27.140 --> 00:16:32.300
could actually tweak them and send
different, different stuff. So, actually,
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
00:16:38.519 --> 00:16:42.850
the ones that we all have experience
because even if you are just using e-mail,
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
00:16:45.920 --> 00:16:52.680
who has who sent you something and to whom
it was sent. Usually yourself. And there
00:16:52.680 --> 00:16:57.800
might be, of course, more recipients. Oh,
yeah. And the question then another
00:16:57.800 --> 00:17:03.769
question is: Which one is actually, if we
have specified for some reason by accident
00:17:03.769 --> 00:17:07.300
or especially if we have specified
different addresses in this envelope in
00:17:07.300 --> 00:17:11.890
the message which one the user will see
the recipient, it's actually the header.
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
00:17:18.010 --> 00:17:22.510
as I was saying, there are actually
standards allow a bit more headers. And
00:17:22.510 --> 00:17:25.880
actually 3 headers "From", "Sender",
"Reply to" which are semantically really
00:17:25.880 --> 00:17:31.080
close and in the standard it's actually
explains when you should be using which
00:17:31.080 --> 00:17:34.040
one. And the funny thing for me is that,
for example "From" header, which is
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
00:17:39.310 --> 00:17:44.450
that you shouldn't have more than one such
header, but the header itself might
00:17:44.450 --> 00:17:48.020
contain multiple addresses. Personally,
I've never received an email which would
00:17:48.020 --> 00:17:53.110
come from different people, but that's
allowed. But the important thing to
00:17:53.110 --> 00:17:57.530
understand here again is the backwards
compatibility that I mentioned before. So
00:17:57.530 --> 00:18:02.480
even though standards explain how you
should use the each header and that you
00:18:02.480 --> 00:18:07.130
shouldn't have more than one of each of
these headers in practice actually can
00:18:07.130 --> 00:18:12.480
send malformed email. You could send email
with multiple headers, the same header
00:18:12.480 --> 00:18:17.040
"From" header multiple times, or you could
send header which does not contain "From"
00:18:17.040 --> 00:18:21.240
but contain "Sender" according to RFC
that's incorrect. But in practice it will
00:18:21.240 --> 00:18:27.550
work. Most organizations, most e-mail
service will try their best to pass your
00:18:27.550 --> 00:18:33.720
completely malformed email because they
really are concerned about lowering the
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
00:18:37.580 --> 00:18:42.160
better to make that everything is working
most of the time. Of course, for
00:18:42.160 --> 00:18:45.670
penetration testers that means that you
can play around with this because there
00:18:45.670 --> 00:18:49.480
are different implementations and it's
exactly which header, for example, if you
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
00:18:53.830 --> 00:18:59.150
particular implementation. So because
there are so many implementations, they
00:18:59.150 --> 00:19:03.720
are interconnected in different ways. You
could and you should as a penetration
00:19:03.720 --> 00:19:09.270
tester try various things, for example,
add the same header multiple times. OK.
00:19:09.270 --> 00:19:13.990
Now that we have covered these basics,
let's actually look into how you would try
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
00:19:18.360 --> 00:19:23.930
this diagram that we have seen before. And
for example, in the first example about
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
00:19:29.960 --> 00:19:33.700
are penetration tester licensed, we have
an arrangement that we are allowed to do
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
00:19:38.920 --> 00:19:44.440
trying to spoof Alice's message. So our
intention is that Bob wants Bob receives
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
00:19:52.580 --> 00:19:57.580
this. Okay. I will not cover the risk. I
think you can imagine that. So, for
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.
00:20:01.430 --> 00:20:06.330
It's one this was used against government
bodies. And when someone sent a fake news
00:20:06.330 --> 00:20:13.660
e-mail to other people, organizations and
so on, and were trying to impersonate some
00:20:13.660 --> 00:20:19.510
some government person. And of course, you
could could imagine yourself how it's not
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
00:20:23.710 --> 00:20:28.450
though Chuck is doing attack, it depends
on your perspective. It might look like
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
00:20:32.480 --> 00:20:37.590
systems. As you can see, Chuck is sending
e-mail directly to Bob's incoming
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
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
00:20:48.540 --> 00:20:52.900
are testing Alice's server. And in this
case, we are trying, again we are Chuck.
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
00:20:58.570 --> 00:21:03.790
interesting question is, which is easier
to protect. It might seem that since in
00:21:03.790 --> 00:21:07.270
the second example, e-mail is actually
going through Alice's systems, that means
00:21:07.270 --> 00:21:11.880
that Alice has more power to do something,
to do some additional checks and balances
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
00:21:16.190 --> 00:21:21.710
first example. So even though our customer
is Alice, we're trying to protect Alice,
00:21:21.710 --> 00:21:26.540
but it's easier to protect in practice
this example where someone is selling,
00:21:26.540 --> 00:21:32.800
sending e-mail, trying to impersonate
Alice. Okay. Oh, yeah. That there is the
00:21:32.800 --> 00:21:37.690
third example, which is if Alice is
communicating with her colleagues inside
00:21:37.690 --> 00:21:41.821
the same organization. Again, we are Chuck
in this case. Again, we will only send the
00:21:41.821 --> 00:21:47.590
e-mail to Alice's incoming server. Not to
outgoing server. Right. So important thing
00:21:47.590 --> 00:21:54.460
to note. And again, in principle, this
third example is the easiest to notice,
00:21:54.460 --> 00:21:59.790
because Alice's organization presumably
knows that her e-mails always should come
00:21:59.790 --> 00:22:03.790
from this particular outgoing server.
Right. Like if we are sending e-mail from
00:22:03.790 --> 00:22:08.780
Alice's colleague, then incoming server in
principle should have all the power, even
00:22:08.780 --> 00:22:15.610
without any standards and stuff like that.
But in practice, sometimes actually quite
00:22:15.610 --> 00:22:24.140
often there will be a specific whitelist
for Alice's own organization. So some
00:22:24.140 --> 00:22:28.880
checks won't happen if incoming server for
Alice is receiving email, which is coming
00:22:28.880 --> 00:22:34.610
from, again, Alice. And by the way,
there's this example. We've seen that for
00:22:34.610 --> 00:22:38.730
the past few years. I think it's not
specific to Latvia. So here, for example,
00:22:38.730 --> 00:22:43.590
is Canada and others,if you can see. This
are these emails which are fake like
00:22:43.590 --> 00:22:48.290
ransomware stuff. Basically, they are
telling you that they have hacked your
00:22:48.290 --> 00:22:53.820
computer or your email. In this case, and
they have arranged all sorts of financial
00:22:53.820 --> 00:22:59.160
activity or have some blackmailing you.
And please send them the money. Your
00:22:59.160 --> 00:23:04.520
money. I mean, your money in bitcoins to
their address. So, these e-mails.
00:23:04.520 --> 00:23:08.920
Interesting part about these e-mails is,
that they are usually in order to prove to
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
00:23:13.210 --> 00:23:20.100
address to your address. So and for many
people, that works. So they see that
00:23:20.100 --> 00:23:22.730
someone has hacked their account,
obviously, because they've received e-mail
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
00:23:28.620 --> 00:23:34.100
e-mails if there haven't been any
protections, haven't been put in place. So
00:23:34.100 --> 00:23:38.120
the important thing, I hope that now no
one in this audience is falling for such
00:23:38.120 --> 00:23:43.910
scam. But if you have some friends or
colleagues that have contacted you and
00:23:43.910 --> 00:23:48.230
told you about such e-mails that they have
received. But one of the things besides
00:23:48.230 --> 00:23:53.110
checking the passwords is starting using
more effective authentification on is a
00:23:53.110 --> 00:23:57.770
just maybe you could tell them that they
should contact their email administrators
00:23:57.770 --> 00:24:03.470
or IT team and ask them about anti
spoofing protection, because obviously if
00:24:03.470 --> 00:24:09.020
they are able to receive such e-mail and
it's not filtered, something is wrong.
00:24:09.020 --> 00:24:16.990
Okay, and now let's see a spoofed SMTP
conversation, so that's example similar to
00:24:16.990 --> 00:24:22.090
previous one. But in this now we are
actually Chuck. So this is sent by Chuck
00:24:22.090 --> 00:24:25.920
to Bob, but we are pretending to be Alice.
The question is, can you see the
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
00:24:30.110 --> 00:24:33.230
difference because there is none
difference. That is the same conversation.
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
00:24:39.540 --> 00:24:43.640
protection. So, yeah, you could just for
example, if you are that guy that is
00:24:43.640 --> 00:24:49.580
sending the fake ransom letters, you can
just write down this text and just dump it
00:24:49.580 --> 00:24:55.830
to telnet and it will work for many
organizations. Not for all. And of course,
00:24:55.830 --> 00:25:01.210
the email admins know this stuff, know
that SMTP is not very reliable in this
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
00:25:05.070 --> 00:25:11.520
some protection, just like ad hoc way. So
no standards just to ransom, add some
00:25:11.520 --> 00:25:15.950
additional filters and stuff into your own
mail. And some of these protections
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
00:25:20.640 --> 00:25:26.260
or it's. I absolutely approve this, for
example. So yeah, go on. But the problem
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
00:25:31.640 --> 00:25:35.100
and we are trying to protect our systems.
So we are Bob, some system administrator
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
00:25:39.730 --> 00:25:44.590
stuff, then what actually can we do? So
one example that I listed here is doing
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
00:25:49.980 --> 00:25:56.970
Alice, we actually check does that email
exist at all? Because many spammers, what
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
00:26:02.000 --> 00:26:08.640
by if you are just running raw SMTP
server. So SMTP callback is basically you
00:26:08.640 --> 00:26:13.300
are when you are receiving email from, for
example. Alice, you are trying. You are
00:26:13.300 --> 00:26:17.220
running, spawning a separate process which
will try to connect back to Alice, etc.
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
00:26:24.500 --> 00:26:27.540
email exists and so on. You are not like,
you actually stop the conversation. You
00:26:27.540 --> 00:26:31.290
don't continue with sending email, but
then your system can automatically find
00:26:31.290 --> 00:26:36.570
that actually this e-mail really exists.
So another way to do this is through
00:26:36.570 --> 00:26:42.030
checking this "Hello". And this is the
first line and the first line, it's,
00:26:42.030 --> 00:26:48.000
normally it should tell you the hostname
of the server that is sending email.
00:26:48.000 --> 00:26:52.580
Interesting part. So according to RFC
again, you shouldn't check it that you
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
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
00:27:04.520 --> 00:27:07.800
all, this hostname, which you are telling
that you have this hostname. First of all,
00:27:07.800 --> 00:27:12.800
that it really points to the same IP
address and then they do the opposite. So
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
00:27:18.880 --> 00:27:23.150
find whether that IP address really
responds to this hostname. So again, as a
00:27:23.150 --> 00:27:26.520
penetration testers we should be aware of
these protections, ad hoc protections,
00:27:26.520 --> 00:27:31.040
because they are if you don't know about
them, you will try running something and
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
00:27:34.700 --> 00:27:40.470
to identify that this organization uses
them. They are easy to bypass so that they
00:27:40.470 --> 00:27:44.530
don't offer good protection. They are
meant to protect from mass abuse from
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
00:27:52.910 --> 00:27:59.380
protection. So which additions to the
protocol actually can we use to protect
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
00:28:06.860 --> 00:28:12.870
like mirror MX system. MX system is the
one which basically Alice can use to
00:28:12.870 --> 00:28:18.150
Alice's server can use to automatically
find the server that belongs to Bob and
00:28:18.150 --> 00:28:24.580
its incoming server. So. SPF is the
opposite of that. So that's an idea is
00:28:24.580 --> 00:28:30.270
here to run the system automatically on
the Bob's incoming server. And now when
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
00:28:35.720 --> 00:28:41.820
addresses actually should belong to
Alice's outgoing server. Right. So it's I
00:28:41.820 --> 00:28:45.780
think it's easy to understand it's
actually a meaningful way. It sounds
00:28:45.780 --> 00:28:52.570
meaningful addition. And the one field
that is checked in this example is this
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
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
00:29:04.610 --> 00:29:08.470
IP address, which is IP, should be IP
address of outgoing server, legitimate
00:29:08.470 --> 00:29:12.780
outgoing server. And then it says this
"-all" which again, is easy to understand.
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,
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,
00:29:22.980 --> 00:29:27.190
then just drop it. And there are multiple
ways to specify the IP address. You could
00:29:27.190 --> 00:29:31.610
just specify the IP address. You could
specify IP subnet, you could specify DNS
00:29:31.610 --> 00:29:37.070
hostname. So it's just for admin. So
basically for a penetration test, it
00:29:37.070 --> 00:29:44.750
doesn't do much different, for admins it's
just easier to maintain these systems. And
00:29:44.750 --> 00:29:49.620
then there are these qualifiers,
qualifiers. This is what's something which
00:29:49.620 --> 00:29:56.160
you put before the methods. For example,
here in this example, IPv4 before doesn't
00:29:56.160 --> 00:30:00.100
have any qualifier. There's no plus or
minus or something. That's because plus is
00:30:00.100 --> 00:30:03.910
assumed by default. So by default,
everything that is listed in SPF record
00:30:03.910 --> 00:30:12.600
will should the match some legitimate SMTP
server, outgoing server. However. There
00:30:12.600 --> 00:30:15.850
are other options you could use minus
which is fail. And that means if something
00:30:15.850 --> 00:30:20.380
matches this record, for example, minus
all is the one which is the most often
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
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
00:30:32.090 --> 00:30:37.150
option, which is softfail, and that's
meant for testing period. So when you are
00:30:37.150 --> 00:30:42.690
just starting to implement SPF, there
might be some. So the problem is that you
00:30:42.690 --> 00:30:47.730
might forget, for example, to add some
SMTP servers. So because you haven't done
00:30:47.730 --> 00:30:52.750
it before, maybe you think you have only
one SMTP actually outgoing server. But in
00:30:52.750 --> 00:30:56.360
fact, you have multiple of them or
multiple ways to send e-mail. So in that
00:30:56.360 --> 00:31:03.600
case, if you were to start set that SPF
record with "fail" strong policy, then
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
00:31:07.230 --> 00:31:13.460
good. However. Here are some other
examples, a bit more complicated. One of
00:31:13.460 --> 00:31:16.400
them is was include. So instead of
defining the policy yourself because
00:31:16.400 --> 00:31:19.270
you're using third party, for example,
Google in this example, and then you will
00:31:19.270 --> 00:31:24.720
just include whatever Google has
published. And the interesting thing is
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
00:31:31.530 --> 00:31:36.890
defined some sort of policy, that the
number looks pretty okay. I guess that's
00:31:36.890 --> 00:31:42.290
for example for most popular domains
that's around 70 percent. But the problem
00:31:42.290 --> 00:31:45.710
is that the majority of them are either
poorly configured or they just use the
00:31:45.710 --> 00:31:51.790
softfail option. And what softfail
practically does is nothing. You still can
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
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
00:32:00.720 --> 00:32:07.940
testing mode. You shouldn't drop e-mail
automatically. Yeah. So. Actually, the
00:32:07.940 --> 00:32:13.910
percentage isn't that great. However, the
most important thing for us as penetration
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
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
00:32:24.670 --> 00:32:30.060
stuff. So first of all, is this softfail
that I mentioned. And that's basically you
00:32:30.060 --> 00:32:33.830
have some rules, rules, rules, and then in
the end, you are putting typically just
00:32:33.830 --> 00:32:41.460
this softfail at all. So if we as a
penetration testers will try spoofing from
00:32:41.460 --> 00:32:46.330
some unknown IP address that hasn't been
listed in the previous rules. Then do
00:32:46.330 --> 00:32:51.520
nothing. Do nothing. I mean, don't drop
email. That is good for us, right? That
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
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
00:33:02.250 --> 00:33:06.590
binary classification, whether something
is good or bad, but they are trying to run
00:33:06.590 --> 00:33:11.320
some scoring. And then it might be that
even if you have this soft fail, they
00:33:11.320 --> 00:33:16.370
won't automatically drop your e-mail, but
maybe they will add some like suspicious
00:33:16.370 --> 00:33:22.540
level to it. But important thing is that
it's not automatically a game over.
00:33:22.540 --> 00:33:29.970
Another thing is this include. So include
is it very convenient when you are using
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
00:33:36.330 --> 00:33:43.100
least even in the standard, it mentions
that it was a poorly chosen name. And the
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
00:33:48.110 --> 00:33:52.720
this included, you shouldn't just copy
paste everything from inside recursively
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
00:33:58.340 --> 00:34:05.480
this include. But then if it fails, it
won't automatically drop the message. It
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
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
00:34:14.510 --> 00:34:20.570
just forget to add this minus all to , or
your system administrator who has
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
00:34:26.470 --> 00:34:34.089
work because I mean, it would because when
the recipient will be checking it minus
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
00:34:39.569 --> 00:34:43.799
second would be if they have added all but
did softfail all. And some admins might
00:34:43.799 --> 00:34:47.809
think that. But that's okay because I'm
including GMail and GMail has this hard
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
00:34:54.409 --> 00:35:00.000
common case, is that something often you
actually see this type of SPF records, but
00:35:00.000 --> 00:35:03.569
there is lots of stuff inside there is IP
addresses. There are these A records,
00:35:03.569 --> 00:35:07.890
there is a MX. There is a pointer.
Basically, everything that the admins
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
00:35:12.990 --> 00:35:17.100
it works. They're not sure what they
should put inside. So, for example, one
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
00:35:24.840 --> 00:35:27.930
commonly most organizations, unless they
are very small and just have one server,
00:35:27.930 --> 00:35:31.059
they will have different servers,
different IP addresses for outgoing mail
00:35:31.059 --> 00:35:34.500
and for incoming mail. That means there is
no practical for this organization,here is
00:35:34.500 --> 00:35:41.109
no practical reason to include MX into SPF
because no, no mail should go out through
00:35:41.109 --> 00:35:45.900
their incoming mail server. And another
case might be that the admins understand
00:35:45.900 --> 00:35:51.470
how it works, but it's really, truly their
architecture is really messy and they are
00:35:51.470 --> 00:35:55.730
sending emails from many, many different
points, which is good for penetration
00:35:55.730 --> 00:36:03.359
testers. That means that they are not well
organized. OK. And then there's another
00:36:03.359 --> 00:36:09.220
flaw, which is that granularity isn't very
well suited. So the only thing you can.
00:36:09.220 --> 00:36:13.799
There are multiple this record types. But
all they do basically are resolve the IP
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
00:36:19.650 --> 00:36:24.230
server. So on one IP, there might be mail
server and web server or database or
00:36:24.230 --> 00:36:28.069
something else. And that means that as a
penetration tester, you can exploit this
00:36:28.069 --> 00:36:32.339
something else. Not mail server itself,
because mailserver usually is pretty like
00:36:32.339 --> 00:36:36.740
low key. There's not many vulnerabilities
there. You just patch them and that's it.
00:36:36.740 --> 00:36:42.740
But those other systems, for example, web,
it's easy to exploit. In most cases. So
00:36:42.740 --> 00:36:46.680
then you can elevate like in some sort
elevate privileges by gaining access
00:36:46.680 --> 00:36:50.809
through some other server on that IP
address or IP range. You can start sending
00:36:50.809 --> 00:36:59.859
mails. They will pass all SPF filters. OK.
So one example is shared hosting, which is
00:36:59.859 --> 00:37:04.950
the very common case and the problem with
shared hosting is that. In this case.
00:37:04.950 --> 00:37:10.359
Okay. You have IP address of SMTP server.
Maybe that's server only used for sending
00:37:10.359 --> 00:37:15.900
mails. But the server itself works not
just for you. It works for many domains,
00:37:15.900 --> 00:37:18.849
maybe hundreds of thousand domains. That
means as an attacker, again, you can
00:37:18.849 --> 00:37:24.289
exploit at least one of them, or for
shared hosting you can just buy. You can
00:37:24.289 --> 00:37:26.940
become a customer of that shared hosting.
You don't even need to exploit anything.
00:37:26.940 --> 00:37:31.750
And then you can potentially start sending
email, which will look good as far as SPF
00:37:31.750 --> 00:37:38.140
is concerned, just like their own. So. And
the another one is this checking wrong
00:37:38.140 --> 00:37:44.960
identifier. And this is probably the
worst, worst problem with SPF. It is that,
00:37:44.960 --> 00:37:49.640
as I mentioned before, the one there are
at least two identifiers. Typically
00:37:49.640 --> 00:37:53.740
envelope sender, the outer one, which
lists the sender, and then there is
00:37:53.740 --> 00:37:58.589
internal one, which is usually "from"
header. But out of those two SPF only
00:37:58.589 --> 00:38:03.140
checks, if SPF is the only technology that
you are using, SPF only checks the first
00:38:03.140 --> 00:38:09.059
one: envelope sender. And as I mentioned,
in most cases, actual users that will
00:38:09.059 --> 00:38:13.279
receive the mail, they won't see envelope
senders. They will see this and this other
00:38:13.279 --> 00:38:17.559
one "from" for example, or one of the
other headers they mention. So this
00:38:17.559 --> 00:38:22.830
behavior is fixed actually by DMARC, which
is the technology that I mentioned. But
00:38:22.830 --> 00:38:27.319
the majority of SPF installations, domains
that are using SPF do not have DMARC, so
00:38:27.319 --> 00:38:31.329
they are not protected by this. So even if
their SPF is completely great for
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
00:38:36.630 --> 00:38:40.430
set envelope sender to something else. For
example, your own controlled address,
00:38:40.430 --> 00:38:49.010
which will pass all SPF checks. But then
inside the "from" you can show the header
00:38:49.010 --> 00:38:56.776
that will match this organization that you
want to pretend to be. Okay. So then there
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,
00:39:02.309 --> 00:39:11.450
SPF is not enough. So DKIM. Sorry, the
wrong letters, Domainkeys identified mail.
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
00:39:15.099 --> 00:39:20.223
name. And what it does, basically, it uses
cryptography, which is nice, right? It's
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
00:39:24.640 --> 00:39:29.870
every mail that is going out through the
DKIM enabled server will get signature,
00:39:29.870 --> 00:39:35.059
which you can, as a recipient, you can
cryptographically verify. So as you can
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
00:39:39.940 --> 00:39:44.160
processed by humans. It's cryptography.
It's meant to be processed by computers.
00:39:44.160 --> 00:39:48.300
But the important part here is basically
the yellow stuff is this cryptographic
00:39:48.300 --> 00:39:55.880
signature. But the green part is what's
called domain identifier. And the red part
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
00:40:02.269 --> 00:40:07.160
idea is that you can have multiple keys
for your organization, for example, your
00:40:07.160 --> 00:40:12.390
organization might be sending mails from
your original SMTP server, then you might
00:40:12.390 --> 00:40:17.650
have a backup one or you might have might
be sending some messages from Google or
00:40:17.650 --> 00:40:21.759
some marketing campaign and so on. And
then each of them might have different
00:40:21.759 --> 00:40:26.970
"red", this parameter. The problem is and
then the recipient will need to run DNS
00:40:26.970 --> 00:40:32.532
query, which is the second example using
this combination of green and red one. And
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
00:40:36.993 --> 00:40:43.799
signature. So it's sounds really nice. The
problem here is no, another problem yet.
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
00:40:48.730 --> 00:40:52.440
the sender side, you need to first
generate public and private keypairr. Then
00:40:52.440 --> 00:40:56.270
you publish the public part in the DNS.
Then you use private key to sign each
00:40:56.270 --> 00:41:00.480
message. Now recipient does sort of the
opposite. They once they receive the
00:41:00.480 --> 00:41:04.380
email, they figure out from this red and
green part they figured out the correct
00:41:04.380 --> 00:41:09.000
DNS record to run, run it, get the public
key and then compare whether this public
00:41:09.000 --> 00:41:12.526
key corresponds to the signature. So it
sounds really nice, right? What's the
00:41:12.526 --> 00:41:19.170
problem? So customers. Selectors, that's
the name. So the problem with that is that
00:41:19.170 --> 00:41:27.309
the selectors there might be multiple
selectors as a DKIM when you are doing
00:41:27.309 --> 00:41:31.670
configuration, you can select as many of
this custom selectors as you want, and the
00:41:31.670 --> 00:41:37.170
recipient doesn't know whether you
actually should have used a selector and
00:41:37.170 --> 00:41:41.599
what selector you should have used. So the
problem is that while, if we are talking
00:41:41.599 --> 00:41:48.690
just about the vanilla DKIM, modifying
existing signature is hard for penetration
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
00:41:52.630 --> 00:41:57.619
removed DKIM at all the header, the
recipient doesn't know that it should have
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
00:42:03.550 --> 00:42:08.640
check the signature, I need to know this
green part. This domain identifier and the
00:42:08.640 --> 00:42:14.712
selector which are part of this header.
Right. So that's a huge problem. And that
00:42:14.712 --> 00:42:20.818
means that. Yeah. That means that we can
actually while we can't spoof DKIM itself,
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
00:42:26.700 --> 00:42:31.499
thing which protected this system, it will
work. So it might not get the green
00:42:31.499 --> 00:42:37.310
checkmark or whatever, but it will get to
the recipient. So. And another thing is
00:42:37.310 --> 00:42:43.040
this domain selector. Why do we even need
to set that? Because the best practice, of
00:42:43.040 --> 00:42:48.280
course, is that you have envelope sender
equal to "from" header equal to this DKIM
00:42:48.280 --> 00:42:52.430
domain selector. Right. So if you are if I
am sending from Alice, then all three
00:42:52.430 --> 00:42:59.029
should be Alice.org or whatever. The
problem is that it's not mentioned in RFC
00:42:59.029 --> 00:43:04.029
that that should be the case. So what
exactly happens when it is not that way?
00:43:04.029 --> 00:43:09.619
For example, on the right side there is
some real domain which was using Gmail,
00:43:09.619 --> 00:43:17.470
Google Apps, Google suite, and in that case
the default by default Google suite will
00:43:17.470 --> 00:43:22.430
sign all messages. But if you do not do
your own configuration, it will sign them
00:43:22.430 --> 00:43:28.369
with domain it controls, which is this
"gappssmtp". And what it means is that
00:43:28.369 --> 00:43:32.579
although technically something has been
signed with DKIM, it wasn't signed in the
00:43:32.579 --> 00:43:36.406
way that you can trace back to your
organisation. It's something completely
00:43:36.406 --> 00:43:40.069
else. What exactly recipient should do in
that case? Should they just ignore it?
00:43:40.069 --> 00:43:43.859
Should they reject the message or
something? So the correct way would be not
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
00:43:49.380 --> 00:43:53.829
it actually depends. So some validators
will just see any DKIM, will validate it
00:43:53.829 --> 00:44:01.228
and will say that's cool that matches RFC.
So but now the interesting part. Modifying
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
00:44:06.710 --> 00:44:11.339
always but sometimes you actually can
modify. The easiest part to modify in the
00:44:11.339 --> 00:44:17.190
messages are headers because DKIM, since
it's placed in headers itself, it does not
00:44:17.190 --> 00:44:21.304
automatically sign old headers. There's
like a chicken and egg problem. So by
00:44:21.304 --> 00:44:26.170
default it only signs one or two headers
and you can specify more headers that need
00:44:26.170 --> 00:44:30.910
to be signed, but it doesn't happen
automatically. So the easy part for
00:44:30.910 --> 00:44:35.569
attacker is to add another header. If
that's somehow helps you in your like
00:44:35.569 --> 00:44:40.400
plan, then that's easy to do. You just add
another header. An interesting part is,
00:44:40.400 --> 00:44:43.940
although the RFC, as I mentioned before,
mentions that some headers such as
00:44:43.940 --> 00:44:49.180
"subject" or "from" should only be present
in one copy. Actually you could add more
00:44:49.180 --> 00:44:53.093
than one for example "from" header, and
what happens in that case is pretty
00:44:53.093 --> 00:44:59.367
interesting. DKIM will match if you have
told to DKIM that "from" header should be,
00:44:59.367 --> 00:45:04.150
for example, signed, then it will match
and sign first "from" header from the
00:45:04.150 --> 00:45:11.279
bottom. But quite a lot of software in our
software email clients will actually only
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
00:45:16.807 --> 00:45:23.940
is that the attacker can mangle or
overwrite headers by just adding new
00:45:23.940 --> 00:45:29.546
headers to the top. And the this actually
problem is mentioned in the DKIM RFC and
00:45:29.546 --> 00:45:33.089
the protection that they propose is this
code Over-Signing or you can go and read
00:45:33.089 --> 00:45:38.885
the RFC. But not everyone is doing that
actually. And however, that only goes to
00:45:38.885 --> 00:45:44.919
the headers. So sometimes that is good.
Sometimes that's not good. Modifying
00:45:44.919 --> 00:45:49.499
message body is actually much harder to
do. Basically the naiv way do it through
00:45:49.499 --> 00:45:54.069
cryptography, which we don't want to do.
And another way is through this one
00:45:54.069 --> 00:45:58.140
parameter, which is body length, and
that's actually like questionable
00:45:58.140 --> 00:46:05.118
functionality that DKIM has. Sometimes you
can specify that the hash like. For
00:46:05.118 --> 00:46:08.789
signing purposes, we shouldn't consider
the whole body, but only first something
00:46:08.789 --> 00:46:13.790
bytes. So that's actually useful in some
cases regarding was a mailing list, but
00:46:13.790 --> 00:46:18.866
for the most part that's not useful. And
in practice, most email software does not
00:46:18.866 --> 00:46:24.500
do this. If it does, then it is
susceptible to potentially to this
00:46:24.500 --> 00:46:28.869
overwriting body as well. You could add
another mime type and then then modify
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
00:46:34.245 --> 00:46:37.569
actually will show, for example, the green
button or whatever, because DKIM, it will
00:46:37.569 --> 00:46:42.634
be valid. So now there's the third
technology, which is called DMARC. And
00:46:42.634 --> 00:46:47.640
again, there is the full name, which is
long, but in this case actually it means
00:46:47.640 --> 00:46:52.424
something. There are two key words:
reporting and conformance. Reporting is
00:46:52.424 --> 00:46:56.660
the one which most admins are familiar
with because that's how DMARC I think
00:46:56.660 --> 00:47:01.619
often is being sold to them. Reporting
means that when you have some problems in
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
00:47:08.390 --> 00:47:13.309
basically you tell them to send you
reports either once per day or every time
00:47:13.309 --> 00:47:16.886
and so on. So for penetration testers,
it's not that useful. Potentially we could
00:47:16.886 --> 00:47:20.509
use that to understand what sort of
configuration is running on the other
00:47:20.509 --> 00:47:25.000
side. But the currently this functionality
actually is not that widely implemented.
00:47:25.000 --> 00:47:30.309
However, the other part conformance, it's
actually really, really, really powerful.
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
00:47:35.251 --> 00:47:39.381
first of all, DKIM had this massive
problem that if you just strip down the
00:47:39.381 --> 00:47:43.109
header, then the recipient has no way of
knowing whether you whether there was
00:47:43.109 --> 00:47:49.377
should have been DKIM in first place. If
you are using DKIM alongside with DMARC
00:47:49.377 --> 00:47:55.269
that fixes the problem, because DMARC
specifies just that you have DMARC itself.
00:47:55.269 --> 00:47:59.220
It means that you're automatically at
least one of the SPF or DKIM should pass.
00:47:59.220 --> 00:48:03.576
So automatically DKIM is like measure
problem solved. The other thing that
00:48:03.576 --> 00:48:08.599
changes is, it changes the semantics for
SPF. Now, SPF, if you have both SPF and
00:48:08.599 --> 00:48:13.150
DMARC, it means that SPF should be checked
against "from" header. And as I mentioned,
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
00:48:17.319 --> 00:48:21.440
the hard to fail mode and so on, it means
that attackers can modify "from" headers
00:48:21.442 --> 00:48:26.710
still and the recipient won't know any
better. So a minimal example of DMARC is
00:48:26.710 --> 00:48:31.210
really, really small. And I think it's
easy to understand. You have just a DMARC
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
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
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
00:48:46.190 --> 00:48:50.680
and DKIM, but you have created DMARC,
effectively what it means is that this
00:48:50.680 --> 00:48:57.550
domain should not send any mail because
for recipient to consider a mail valid at
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.
00:49:02.279 --> 00:49:07.480
So in fact what it means is that most
domains out there should consider enabling
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
00:49:15.471 --> 00:49:22.019
wild, these DMARC records might be much
longer, but it's not of much use to
00:49:22.019 --> 00:49:26.009
penetration testers. So important part
here is again, this is this policy which
00:49:26.009 --> 00:49:31.184
can be three values "none", "quarantine"
and "reject". And if it is "quarantine",
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.
00:49:39.109 --> 00:49:42.619
If it's "reject", it should be rejected
outright. And if it's "none", it means
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
00:49:47.960 --> 00:49:52.400
shows that actually even though DMARC is
really like the best technology out of
00:49:52.400 --> 00:49:59.655
these three, it's not really widely used,
unfortunately for defenders. Quite a nice
00:49:59.655 --> 00:50:05.070
fact for all penetration testers out
there. That means that you can, in fact
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.
00:50:14.550 --> 00:50:18.480
What happens if actually someone has
implemented DMARC? Does that mean that now
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?
00:50:23.526 --> 00:50:29.039
No, it doesn't. So in practice, if someone
has implemented both DKIM and DMARC, but
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
00:50:33.859 --> 00:50:38.470
pretty powerful and the major flaw that it
had DMARC solves. So this combination is
00:50:38.470 --> 00:50:44.680
really cool in theory. In practice, the
problem is that in order to protect your
00:50:44.680 --> 00:50:49.751
own mails, the recipient side should
validate both DKIM and DMARC and
00:50:49.751 --> 00:50:53.932
unfortunately, quite a lot of software
still does not do that. One such software
00:50:53.932 --> 00:50:57.920
is Microsoft Exchange. And even if you are
not running Microsoft Exchange, chances
00:50:57.920 --> 00:51:02.049
are good that some of the partners that
you are communicating with are running
00:51:02.049 --> 00:51:05.700
Microsoft Exchange, and by default it
doesn't have any functionality to parse
00:51:05.700 --> 00:51:12.619
DKIM. So in fact, most systems still need
to enable SPF just for practical purposes,
00:51:12.619 --> 00:51:16.609
which is good for penetration testers
because if SPF and DMARC as enabled by
00:51:16.609 --> 00:51:21.502
default together, then again that fixes
one of the major problems with SPF, but
00:51:21.502 --> 00:51:25.864
does not automatically fix other problems
because there's not enough granularity and
00:51:25.864 --> 00:51:32.119
the potential for misconfiguration. So.
And the interesting fact is that DMARC
00:51:32.119 --> 00:51:37.970
only requires that one of the other
technologies SPF or DKIM is passed in
00:51:37.970 --> 00:51:42.749
order to consider email valid. There is no
way in DMARC, even though there are many
00:51:42.749 --> 00:51:45.680
others like selectors. There is no way to
specify that both of them should be valid
00:51:45.680 --> 00:51:50.019
or that DKIM should be preferred to SPF.
In practice, what it means is that for
00:51:50.019 --> 00:51:54.950
most systems that enable all three of
them, which is a good practical solution
00:51:54.950 --> 00:51:59.849
from penetration tester side we can just
ignore DKIM outright and just focus on SPF
00:51:59.849 --> 00:52:05.170
because the SPF is the weakest link in
this situation. Okay. So just a minute for
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
00:52:11.559 --> 00:52:17.140
sorry. Yeah. So one really important note
is, when you are testing the systems,
00:52:17.140 --> 00:52:22.270
consider both scenarios. So don't focus
just on send. If you are, for example,
00:52:22.270 --> 00:52:27.599
testing Alice. Alice is the organisation
that is your customer. Don't just focus on
00:52:27.599 --> 00:52:33.569
testing emails sent impersonating Alice,
but also as the other side. Because in
00:52:33.569 --> 00:52:38.670
this here you can see that it's easy to
implement for example, SPF and DMARC
00:52:38.670 --> 00:52:43.961
because for both of them only you only
need DNS configuration. Just one record
00:52:43.961 --> 00:52:48.779
per each. However actually testing them
like well validating them properly is
00:52:48.779 --> 00:52:52.643
harder. For the first you need the
software support, you need to configure it
00:52:52.643 --> 00:52:56.585
correctly as well. So in practice it might
be that many of organisations that have
00:52:56.585 --> 00:53:01.500
enabled DMARC or SPF on the DNS side for
outgoing mails, they are not actually
00:53:01.500 --> 00:53:07.960
properly validating it. Yeah. Okay. Sorry,
I don't have time for that. So probably.
00:53:07.960 --> 00:53:16.009
That's it. Sorry. Maybe some questions.
00:53:16.009 --> 00:53:24.601
applause
00:53:24.601 --> 00:53:29.719
Herald: Thanks, Andrew, for this nice
talk. Sure. We have time for a couple of
00:53:29.719 --> 00:53:33.839
questions. So there I already see one
person, microphone number two.
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
00:53:40.150 --> 00:53:44.339
get sent by my recipients?
A: Yeah. So this is a really good
00:53:44.339 --> 00:53:49.940
question. We as a CERT, we are really
suggesting everyone to enable this tool,
00:53:49.940 --> 00:53:55.190
but unfortunately, as far as I know, all
the tools that are popular on the
00:53:55.190 --> 00:53:59.670
Internet, they are collecting some data on
you. So they are using it for marketing
00:53:59.670 --> 00:54:04.412
purposes, do they are not very good for
privacy, if you are concerned about that.
00:54:04.412 --> 00:54:07.880
So you need to implement something
yourself or you need to look at some,
00:54:07.880 --> 00:54:12.180
start some open source project maybe.
Herald: OK. Microphone number one, please.
00:54:12.180 --> 00:54:16.428
M1: Thank you for the good talk. Me
myself, I would consider myself an mail
00:54:16.428 --> 00:54:23.609
administrator. I sometimes get advised to
shorten your SPF record because if it's
00:54:23.609 --> 00:54:28.859
too long, it gets dropped anyway. For
that, I sometimes get advised to drop the
00:54:28.859 --> 00:54:34.930
PTR record. But in your talk, you say the
PTR record is useful for reverse DNS
00:54:34.930 --> 00:54:39.549
checking, which I find very useful as
well. How are you about shortening your
00:54:39.549 --> 00:54:42.920
SPF and how are you about the PTR record
in general?
00:54:42.920 --> 00:54:47.530
A: Well, it really depends on your
particular use case. So it might be the
00:54:47.530 --> 00:54:51.230
case that some organizations really need
this longer SPF and there's not no way
00:54:51.230 --> 00:54:55.799
around that you could do. What you could
do is include this, include use includes
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
00:55:01.479 --> 00:55:07.755
like your record doesn't become longer if
you include and use many includes. But the
00:55:07.755 --> 00:55:12.119
problem, which I would suggest to you is
actually reconsider whether it's a really
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
00:55:16.970 --> 00:55:20.499
common problem, is that unless you are
Google or something like that, you don't
00:55:20.499 --> 00:55:26.660
really need that long SPF. It's probably
some problem with some. Yeah. So it's
00:55:26.660 --> 00:55:36.489
probably an error for most organizations.
Herald: OK. Well, very. Just briefly.
00:55:36.489 --> 00:55:40.496
Number 1
M1: On the PTI rocker record. I heard that
00:55:40.496 --> 00:55:43.489
it's dropped. Not dropped from the
standards, but it's not in the standards.
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.
00:55:48.859 --> 00:55:53.599
I don't I'm not aware that it will be
automatically dropped somewhere. Shouldn't
00:55:53.599 --> 00:55:56.380
be a problem.
Herald: We have a couple of more
00:55:56.380 --> 00:55:59.349
questions here. So number six in the very,
very back.
00:55:59.349 --> 00:56:07.420
M6: Thank you for your talk. That's not
directly related, but even it should be
00:56:07.420 --> 00:56:13.800
related. If mail server accepts because
DKIM, DKARC and SPF, everything is fine,
00:56:13.800 --> 00:56:18.779
but especially Google for a lot of
organizations, the mail is delivered but
00:56:18.779 --> 00:56:24.089
classified as spam. It means on the inbox
of the recipient, it is not displayed.
00:56:24.089 --> 00:56:28.069
Have you a solution to solve this problem
against Google?
00:56:28.069 --> 00:56:33.630
A: Yeah. OK. So I have like different
opinions about that because one thing
00:56:33.630 --> 00:56:38.787
which actually enables which we actually
should be doing. Thank you Google. Is
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
00:56:42.859 --> 00:56:47.879
percentage of even improperly configured
SPF. The only reason there are 70 percent
00:56:47.879 --> 00:56:52.829
websites are using SPF is because that
they need to communicate with Google. And
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.
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
00:57:04.269 --> 00:57:09.527
it does. But I understand the real admins
which have this problem. Google has the
00:57:09.527 --> 00:57:15.239
tool. You probably know about it. Where
you can check what it considers about your
00:57:15.239 --> 00:57:19.323
domain. So you need to consider this
problem on a case by case basis. Quite
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
00:57:23.559 --> 00:57:28.576
configured correctly. So that's what the
talk was about. So you have it. You
00:57:28.576 --> 00:57:31.259
probably think that you have configured it
correctly, but there are some errors.
00:57:31.259 --> 00:57:35.249
Herald: Okay, let's give priority to the
Internet.
00:57:35.249 --> 00:57:40.170
Signal Angel: We have one question from
the Internet. Well, attempting to verify
00:57:40.170 --> 00:57:43.819
and address how to handle no reply email
addresses.
00:57:43.819 --> 00:57:49.999
A: No reply, I'm sorry. Can you read it
again, please?
00:57:49.999 --> 00:57:55.170
Signal Angel: When attempting to verify an
address, how to handle noreply Email
00:57:55.170 --> 00:58:04.529
addresses.
A: Maybe it was about the noreply header ?
00:58:04.529 --> 00:58:10.650
Or not existing IP addresses ?
Signal Angel: How to handle email. No
00:58:10.650 --> 00:58:14.809
reply email adresses.
A: I will try to get an answer to how I
00:58:14.809 --> 00:58:21.532
understand it. So what often happens is
that what often happens is that the email
00:58:21.532 --> 00:58:25.294
will be sent from nonexisting addresses.
So maybe that's what the question was. For
00:58:25.294 --> 00:58:29.789
example, there is "no reply", and it's not
the problem itself. No reply. The problem
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
00:58:34.339 --> 00:58:38.816
have an answer for that because according
to RFC, you should you should still accept
00:58:38.816 --> 00:58:43.627
it. Practically, as I said, lots of mail
systems already are dropping this
00:58:43.627 --> 00:58:46.420
addresses if you're sending from not
existing unless you are Google or
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
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
00:58:54.779 --> 00:59:00.309
situation, create the address, make it
like a remove all the email that comes
00:59:00.309 --> 00:59:03.640
there, but create the real address so that
your acceptable. If you are on the other
00:59:03.640 --> 00:59:08.269
side. So you are receiving this email. It
depends on this particular use case. So
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
00:59:12.099 --> 00:59:16.220
contact them, then you should decide what
is the risk, if you are dropping these
00:59:16.220 --> 00:59:23.920
addresses, are they important for you? So
according to RFC you should receive and
00:59:23.920 --> 00:59:28.660
process this addresses.
Herald: Okay. Microphone number four,
00:59:28.660 --> 00:59:33.040
please.
M4: Hey, thank you for this talk. Do you
00:59:33.040 --> 00:59:40.630
know about effort to solve problems with
big email senders like online booksellers,
00:59:40.630 --> 00:59:47.450
which are very great because they don't
seem to have their own SPF records, for
00:59:47.450 --> 00:59:53.253
example, in in control.
A: Yeah. So in many cases you can just
00:59:53.253 --> 00:59:56.711
contact them. So it's just the question
that they haven't thought about it. Or
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.
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
01:00:05.249 --> 01:00:10.619
this problem with some large company in
particular country, I would suggest to
01:00:10.619 --> 01:00:14.470
contact CERT. Even if it's not a
government organization, for example, in
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
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
01:00:21.892 --> 01:00:26.289
maybe one option for you. But the
practices that if something looks to you
01:00:26.289 --> 01:00:30.060
as a third party, as a wrong
configuration, that is one I couldn't
01:00:30.060 --> 01:00:34.400
mention in this talk. If something isn't
perfectly secure, it doesn't mean that
01:00:34.400 --> 01:00:39.460
it's wrong. There might be actually
business case why it should be this way.
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
01:00:42.229 --> 01:00:46.700
something like that. And if they have
tested and they know that when they enable
01:00:46.700 --> 01:00:51.697
very strict configuration, some percentage
of their emails just doesn't come. Not
01:00:51.697 --> 01:00:55.762
because of their problem, because of
someone else's problem. Right. But then
01:00:55.762 --> 01:00:59.759
there is actually a real business case
that they they are not. It would be stupid
01:00:59.759 --> 01:01:04.489
for them to enable this, you know, to
strict configuration, knowing that it will
01:01:04.489 --> 01:01:08.970
damage their business. That makes sense,
right?
01:01:08.970 --> 01:01:13.479
Herald: Okay. We are unfortunately running
out of time for those who are on the
01:01:13.479 --> 01:01:17.755
microphones. please just line up with the
speaker next to the desk. He's gonna talk
01:01:17.755 --> 01:01:21.195
to you. Perfectly sure. And.
01:01:21.195 --> 01:01:25.159
applause
01:01:25.159 --> 01:01:40.959
36C3 postroll
01:01:40.959 --> 01:01:53.000
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!