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