Return to Video

36C3 - Email authentication for penetration testers

  • 0:00 - 0:22
    36C3 preroll music
  • 0:22 - 0:29
    Herald: So, have you ever wondered how to
    almost perfectly fake an email? Then you
  • 0:29 - 0:33
    might be actually in the right talk here.
    We have our next speaker. Andrew, who is
  • 0:33 - 0:41
    currently working for the National CERT of
    Latvia as a security researcher. And he's
  • 0:41 - 0:50
    going to talk about e-mail counterfeiting
    and strategies for modern anti-spoofing.
  • 0:50 - 0:53
    Stage is yours.
  • 0:53 - 1:04
    Applause
  • 1:04 - 1:14
    Andrew: So. Greetings. I'm Andrew and I
    work for Latvian National CERT. One of our
  • 1:14 - 1:21
    current goals is improving the state of
    email security in our country and which we
  • 1:21 - 1:26
    mostly do through raising awareness about
    this issue and communicating best
  • 1:26 - 1:31
    practices. And of course we are not the
    only organization that is doing that.
  • 1:31 - 1:34
    There are many more CERTs in other
    countries and there are various
  • 1:34 - 1:39
    nongovernmental organizations that are
    doing the same. And commercial entities.
  • 1:39 - 1:46
    However, so far, frankly speaking, our
    collective progress has been quite
  • 1:46 - 1:54
    underwhelming. So for example, here is the
    one stat which is the usage of one
  • 1:54 - 2:00
    specific technology, DMARC, which as you
    will learn in this talk, is quite
  • 2:00 - 2:07
    important and I hope that everyone will
    start using it. So on the left. There are
  • 2:07 - 2:11
    twenty thousand domains across all the
    world which are important domains for
  • 2:11 - 2:16
    important organizations that truly should
    know better. And on the right side we see
  • 2:16 - 2:25
    the top 50, top 500 EU retailer domains
    and across both of these groups two thirds
  • 2:25 - 2:30
    haven't even configured DMARC yet. And out
    of those that have configured majority
  • 2:30 - 2:36
    hasn't enabled strict policy yet. So if
    there is just one key takeaway from this
  • 2:36 - 2:41
    talk, I hope that it will be that everyone
    should start using DMARC. It is important
  • 2:41 - 2:49
    to use it even for domains that are not
    supposed to send email. So, one
  • 2:49 - 2:57
    explanation for these low adoption rates,
    I think, is that, there are seemingly too
  • 2:57 - 3:04
    many competing technologies. This is the
    contents for my talk. And I really tried
  • 3:04 - 3:12
    to do my best to trim it down. But as you
    can see, there are three abbreviations, well and
  • 3:12 - 3:19
    SMTP and out of this, SPF, DKIM and DMARC
    actually two are i don't even remember the
  • 3:19 - 3:26
    whole name for them. But still, they are
    all important. And of course, this problem
  • 3:26 - 3:29
    that there are too many buzzwords, too
    many technologies, and it's not clear
  • 3:29 - 3:35
    which one which ones we should use, it's
    not specific to email. And we have this
  • 3:35 - 3:40
    across the industry and, ah, security
    industry, i think by now we have found at
  • 3:40 - 3:48
    least one way to solve it. And it is
    penetration testing. So when the
  • 3:48 - 3:53
    penetration test has been run properly and
    the results have been published, then we
  • 3:53 - 3:58
    can start talking. We can shift the
    conversation from talking about whether
  • 3:58 - 4:04
    your organization prefers technology A or
    technology B we can instead start talking
  • 4:04 - 4:10
    about the questions that really matter,
    such like: Is it possible for someone for
  • 4:10 - 4:15
    some third party to spoof your
    organization's e-mails and to send such
  • 4:15 - 4:21
    e-mails to your, for example, customers or
    your partners or to media organizations in
  • 4:21 - 4:25
    such a way that they will think that the
    emails really came from within your
  • 4:25 - 4:32
    organization? So that's why penetration
    testers are the key audience for this
  • 4:32 - 4:36
    talk. However, I hope that any blue
    teamers in the audience also will find
  • 4:36 - 4:41
    this talking interesting. I'm sure that
    you already know all the basics about the
  • 4:41 - 4:44
    email and about these technologies, but
    looking at the problem from the different
  • 4:44 - 4:50
    side from attacker's perspective sometimes
    can really put things into perspective. It
  • 4:50 - 4:55
    can help for you understand what you
    should focus on when protecting your
  • 4:55 - 5:01
    environment. And finally, the SMTP
    protocol. The technology that runs
  • 5:01 - 5:08
    underneath our e-mail conversations is
    actually relatively easy to understand.
  • 5:08 - 5:14
    And so. And also the lessons learned from
    all of this journey from SMTP, how it
  • 5:14 - 5:21
    became and how it's possible to spoof it
    and all the technologies that are trying
  • 5:21 - 5:28
    to prevent spoofing. I think it's a
    interesting case study and it should be
  • 5:28 - 5:34
    interesting to follow even for people who
    are new to e-mail. Um, finally. Threat
  • 5:34 - 5:41
    landscape. So email security is quite a
    wide topic. And so today I will only focus
  • 5:41 - 5:48
    on one small part of it, which is
    successful spoofing of e-mails. Tampering
  • 5:48 - 5:55
    attacks. And I know that many, penetration
    testers already, incorporate some part of
  • 5:55 - 6:01
    phishing or spear phishing, emulation
    into their engagements and. But as far as
  • 6:01 - 6:07
    I know, they mostly do it from the, social
    engineering perspective using such tools
  • 6:07 - 6:13
    as a social engineering toolkit, for
    example. And it's, uh, I don't want to
  • 6:13 - 6:17
    argue, though, that it's important to do
    that and to demonstrate to the customer
  • 6:17 - 6:24
    that what risks are in regards with social
    engineering. However, I think you're doing
  • 6:24 - 6:28
    a disservice to the customer if that's the
    only thing that you are testing from the
  • 6:28 - 6:33
    email perspective, because from the
    customers, from managers perspective that
  • 6:33 - 6:39
    are reading your reports, if they only
    mention social engineering attacks, then
  • 6:39 - 6:45
    the logical conclusion is, that the best
    way to mitigate these threats is by
  • 6:45 - 6:52
    educating your personnel, especially those
    that are least technical, as you will see
  • 6:52 - 6:55
    in this talk. There are quite a lot of
    attacks and many organizations are
  • 6:55 - 7:00
    susceptible to them, which are much better
    than that. And no amount of user education
  • 7:00 - 7:04
    will help here because we can't expect
    users to check headers, for example,
  • 7:04 - 7:11
    manually. So we actually need to improve
    our e-mail infrastructure. No way around
  • 7:11 - 7:17
    it. And finally, before we move on to
    actual technical stuff, there's a little
  • 7:17 - 7:22
    secret, which I think might help people
    that are not working in the email industry
  • 7:22 - 7:28
    understand why we have such problems and
    is that, for email admins historically,
  • 7:28 - 7:38
    um, they value availability of their
    system and reliable reliability much more
  • 7:38 - 7:45
    than security. And that's because that's
    not an ideological decision. It's a very
  • 7:45 - 7:50
    pragmatic one. So, for example, if you are
    an e-mail an email admin in an
  • 7:50 - 7:56
    organization and some of your customers
    stop receiving invoices, your management
  • 7:56 - 8:01
    will find you and will inform you about it
    and will ask you a really nicely to fix it
  • 8:01 - 8:06
    as soon as possible, even if it's not your
    fault, if it might happen that the problem
  • 8:06 - 8:14
    is on the other side of the email. Not on
    your server. And the for example, if,
  • 8:14 - 8:20
    other example, if you, if some of your,
    some of your employees can't receive
  • 8:20 - 8:25
    e-mail soon enough, for example, to
    restore the password or to verify the
  • 8:25 - 8:30
    email or to use multi factor
    authentication token and they can't log
  • 8:30 - 8:34
    into some important systems again, they
    will find you on though you will need to
  • 8:34 - 8:40
    solve that. But if your system is has some
    security vulnerabilities, if it's assessed
  • 8:40 - 8:46
    susceptible to spoofing attacks and so on,
    then not users, no management will
  • 8:46 - 8:51
    normally notice it. You might not not
    notice it, but you are. You have this
  • 8:51 - 8:56
    vulnerability. So that's why obviously
    penetration testers are important. Okay.
  • 8:56 - 9:01
    Now we can finally start talking about the
    technical stuff. So and we will start with
  • 9:01 - 9:07
    the short introduction to SMTP protocol.
    SMTP is the protocol that underlies all
  • 9:07 - 9:12
    email communications and it's actually
    pretty easy to follow. So here's a data
  • 9:12 - 9:18
    flow of what's happening when one person
    sends e-mail to another person. For
  • 9:18 - 9:21
    example Alice is sending to Bob and
    they're using different they are working
  • 9:21 - 9:25
    for different companies. They use
    different domains. So what's happening
  • 9:25 - 9:29
    here is that both of them would say use
    email clients such as Outlook or
  • 9:29 - 9:35
    Thunderbird. And Alice is sending email.
    It's going through this protocol SMTP to
  • 9:35 - 9:42
    Alice's mail server. But important to note
    is that this is an outgoing e-mail server.
  • 9:42 - 9:45
    Usually organizations will have two types
    of servers, one for incoming transactions
  • 9:45 - 9:49
    and one for outgoing and for smaller
    organizations it might be one server, but
  • 9:49 - 9:52
    again, it's important for penetration
    tester to think of this as different
  • 9:52 - 9:57
    systems because they will have even if
    it's physically one machine, it will have
  • 9:57 - 10:01
    different configuration for outgoing mail
    and for incoming mail. So as a penetration
  • 10:01 - 10:05
    tester you need to check both of them.
    Okay. Now, when Alice's server tries to
  • 10:05 - 10:12
    send email to Bob's server, there is sort
    of a problem in that the server needs to
  • 10:12 - 10:16
    somehow automatically find what is the
    other server to send the email and it is
  • 10:16 - 10:25
    done through this blue box MX which is DNS
    specific DNS record type MX. So that's
  • 10:25 - 10:30
    something that is maintained by Bob's
    organization. So Bob's organization, if
  • 10:30 - 10:35
    they want to receive e-mail, they create
    this DNS record. And I say that. Okay. If
  • 10:35 - 10:39
    you want to send e-mail to us, please use
    this particular server. So it should point
  • 10:39 - 10:44
    to Bob's server. And Alice's outgoing
    server knowing Bob's incoming server
  • 10:44 - 10:51
    address can communicate to that. And then
    later, Bob, will receive its e-mail. So
  • 10:51 - 10:55
    the part that we as penetration testers
    will be trying to breach is actually
  • 10:55 - 11:00
    between Alice's server and between Bob
    Server. And then we need to think about
  • 11:00 - 11:04
    the second example, which is the opposite
    way. And you might think that it's a
  • 11:04 - 11:07
    pointless example because we are just
    basically changing the direction of
  • 11:07 - 11:11
    traffic. But the important part here is
    for us as penetration testers to
  • 11:11 - 11:17
    understand that our client only controls
    part of this transaction. If our client,
  • 11:17 - 11:21
    let's say, for the rest of this
    presentation is Alice or Alice's
  • 11:21 - 11:27
    organization, then in the second example
    when we are sending mail from Bob to
  • 11:27 - 11:35
    Alice, then we'll be sending emails only.
    Basically, part of this transaction will
  • 11:35 - 11:41
    go through Alice's servers. In the first
    example, if we were sending email from
  • 11:41 - 11:46
    Alice to Bob, it wouldn't be so. So if
    it's a bit confusing, that's okay. We will
  • 11:46 - 11:52
    return to that a bit later. And finally,
    there is a third example which looks
  • 11:52 - 11:56
    similar, but not quite. And that's if
    Alice is communicating. Alice is our
  • 11:56 - 12:01
    customer. And if she is communicating with
    her coworkers, which are using the same
  • 12:01 - 12:04
    organization, same e-mail server, same
    domain. In that example, again, there will
  • 12:04 - 12:09
    be to at least logically two email
    servers, outgoing server and incoming
  • 12:09 - 12:16
    server. But both of them will belong to
    our customer. So right now, if you are not
  • 12:16 - 12:20
    familiar with e-mail, you can. It's
    just interesting to try to think which of
  • 12:20 - 12:28
    these scenarios, three scenarios, which of
    them are easier to protect? And a bit
  • 12:28 - 12:32
    later we will see how it's actually
    happening. Okay. And then we need to look
  • 12:32 - 12:38
    at what actually is being sent, when email
    is being sent. So again, it's using SMTP
  • 12:38 - 12:45
    protocol and it's really nice protocol you
    can. As you can see, it's just text. So
  • 12:45 - 12:48
    it's plain text protocol and it's very
    easy to play around because you can just
  • 12:48 - 12:54
    open telnet connection to the right server
    and you can try writing down the commands
  • 12:54 - 12:59
    just with your hands. So you can try
    mangling something or modifying or trying
  • 12:59 - 13:05
    different, different, different types and
    see in real time how it was going on. So
  • 13:05 - 13:11
    on the left side we see here two parts
    which are defined by SMTP. So first of
  • 13:11 - 13:15
    all, there comes SMTP envelope, which
    basically you connect the server, say
  • 13:15 - 13:22
    hello, then you say what. Specify the
    sender of email and recipient. "mail from"
  • 13:22 - 13:27
    is sender. Recipient is Bob, for example.
    And then the second part starts with data
  • 13:27 - 13:32
    and ends with quit. And that's the part
    which is called Content/Message. So just
  • 13:32 - 13:35
    if you want to play around with it, a bit
    more, this is defined by a different
  • 13:35 - 13:38
    standard, which is not that important for
    penetration testers but if you want to
  • 13:38 - 13:44
    look into details and it might be
    important. And this internal message,
  • 13:44 - 13:49
    which is called either Content or SMTP
    message, it again, it contains two parts.
  • 13:49 - 13:53
    One is headers and another is body. And I
    think some people might not be familiar
  • 13:53 - 13:58
    with email, but probably everyone is
    familiar in this audience with HTTP and
  • 13:58 - 14:03
    this looks quite, quite the same. So easy
    to understand. But the interesting part
  • 14:03 - 14:09
    here is that you might have noticed that
    we have Alice's and Bob's addresses twice.
  • 14:09 - 14:14
    Right. For example, Alice's is specified
    on the second line "mail from". And then
  • 14:14 - 14:20
    we have the same address. alice @ her
    organization in "From" header. The red
  • 14:20 - 14:27
    ones are the headers. And the same goes
    for Bob. So why is that? Well, it comes
  • 14:27 - 14:33
    down to how we see e-mail. I as a normal
    regular person who has used email in
  • 14:33 - 14:39
    past quite a lot, i usually see them as
    described on the left side, which is a
  • 14:39 - 14:45
    sort of postcard. So on a postcard there
    is someone who has sent it. The sender.
  • 14:45 - 14:49
    There is the recipient. That's usually me.
    I'm receiving. And then there's some
  • 14:49 - 14:54
    message. So at least that's how I
    perceived it before I learned a bit more
  • 14:54 - 14:59
    about it. But email admins and the
    standard bodies, they see this situation
  • 14:59 - 15:05
    as the one which is shown on the right,
    which is. There is an envelope and inside
  • 15:05 - 15:10
    the envelope then there is this message or
    a postcard maybe. So you have two
  • 15:10 - 15:15
    addresses in this scenario. You specified
    the address from and to whom you are
  • 15:15 - 15:21
    sending the envelope, which is the part
    that post office, for example, will look.
  • 15:21 - 15:25
    But post office won't look generally
    inside your envelope and inside the
  • 15:25 - 15:29
    envelope there is another message, and
    that is the internal message is actually
  • 15:29 - 15:34
    meant for a recipient. So actually, you
    could do even more and you could even put
  • 15:34 - 15:40
    the whole envelope with the message of the
    postcard inside another envelope. And this
  • 15:40 - 15:46
    sounds crazy to me as a regular person,
    but actually e-mail allows that. And in
  • 15:46 - 15:50
    the RFC the standard document, there are
    some examples why that would be necessary.
  • 15:50 - 15:57
    Why why such why such things are allowed.
    But but they are confusing. And so as a
  • 15:57 - 16:03
    result, it is the here in this first
    example, we see that we generally we are
  • 16:03 - 16:08
    specifying the same address twice. But as
    a penetration tester the question that
  • 16:08 - 16:12
    we should be asking is: So is that
    required, actually? Is that always true or
  • 16:12 - 16:17
    is it just like a wishful thinking? And
    it's actually wishful thinking. So
  • 16:17 - 16:21
    standards specifically do not say that you
    should be specifying the same address for
  • 16:21 - 16:27
    recipient or for "From" from the sender on
    the envelope and inside a message. So you
  • 16:27 - 16:32
    could actually tweak them and send
    different, different stuff. So, actually,
  • 16:32 - 16:39
    there are much more headers than what I
    showed. The ones I showed I think are just
  • 16:39 - 16:43
    the ones that we all have experience
    because even if you are just using e-mail,
  • 16:43 - 16:46
    that's usually the stuff that you see or
    see the date, you see the subject, you see
  • 16:46 - 16:53
    who has who sent you something and to whom
    it was sent. Usually yourself. And there
  • 16:53 - 16:58
    might be, of course, more recipients. Oh,
    yeah. And the question then another
  • 16:58 - 17:04
    question is: Which one is actually, if we
    have specified for some reason by accident
  • 17:04 - 17:07
    or especially if we have specified
    different addresses in this envelope in
  • 17:07 - 17:12
    the message which one the user will see
    the recipient, it's actually the header.
  • 17:12 - 17:18
    So inside that the message is the one
    which is intended for the user. OK. So and
  • 17:18 - 17:23
    as I was saying, there are actually
    standards allow a bit more headers. And
  • 17:23 - 17:26
    actually 3 headers "From", "Sender",
    "Reply to" which are semantically really
  • 17:26 - 17:31
    close and in the standard it's actually
    explains when you should be using which
  • 17:31 - 17:34
    one. And the funny thing for me is that,
    for example "From" header, which is
  • 17:34 - 17:39
    usually the one with that we see it might
    contain . By reading the RFC you will see
  • 17:39 - 17:44
    that you shouldn't have more than one such
    header, but the header itself might
  • 17:44 - 17:48
    contain multiple addresses. Personally,
    I've never received an email which would
  • 17:48 - 17:53
    come from different people, but that's
    allowed. But the important thing to
  • 17:53 - 17:58
    understand here again is the backwards
    compatibility that I mentioned before. So
  • 17:58 - 18:02
    even though standards explain how you
    should use the each header and that you
  • 18:02 - 18:07
    shouldn't have more than one of each of
    these headers in practice actually can
  • 18:07 - 18:12
    send malformed email. You could send email
    with multiple headers, the same header
  • 18:12 - 18:17
    "From" header multiple times, or you could
    send header which does not contain "From"
  • 18:17 - 18:21
    but contain "Sender" according to RFC
    that's incorrect. But in practice it will
  • 18:21 - 18:28
    work. Most organizations, most e-mail
    service will try their best to pass your
  • 18:28 - 18:34
    completely malformed email because they
    really are concerned about lowering the
  • 18:34 - 18:38
    support costs. So if something does not
    work, then you will come to them. So it is
  • 18:38 - 18:42
    better to make that everything is working
    most of the time. Of course, for
  • 18:42 - 18:46
    penetration testers that means that you
    can play around with this because there
  • 18:46 - 18:49
    are different implementations and it's
    exactly which header, for example, if you
  • 18:49 - 18:54
    have two headers, will be shown or will be
    used for some algorithm. It depends on the
  • 18:54 - 18:59
    particular implementation. So because
    there are so many implementations, they
  • 18:59 - 19:04
    are interconnected in different ways. You
    could and you should as a penetration
  • 19:04 - 19:09
    tester try various things, for example,
    add the same header multiple times. OK.
  • 19:09 - 19:14
    Now that we have covered these basics,
    let's actually look into how you would try
  • 19:14 - 19:18
    to spoof an e-mail, for example. Yeah. And
    here we are again, we are coming back to
  • 19:18 - 19:24
    this diagram that we have seen before. And
    for example, in the first example about
  • 19:24 - 19:30
    Alice is sending email to Bob. Let's say
    we are, Chuck. So we are a third party. We
  • 19:30 - 19:34
    are penetration tester licensed, we have
    an arrangement that we are allowed to do
  • 19:34 - 19:39
    this and we are trying to send spoofed
    e-mail to Bob. And in this example, we are
  • 19:39 - 19:44
    trying to spoof Alice's message. So our
    intention is that Bob wants Bob receives
  • 19:44 - 19:53
    email. It should look to them, to the Bob,
    that email was sent by Alice. So risk for
  • 19:53 - 19:58
    this. Okay. I will not cover the risk. I
    think you can imagine that. So, for
  • 19:58 - 20:01
    example, you could do fake news is one of
    the problems that we have seen in Latvia.
  • 20:01 - 20:06
    It's one this was used against government
    bodies. And when someone sent a fake news
  • 20:06 - 20:14
    e-mail to other people, organizations and
    so on, and were trying to impersonate some
  • 20:14 - 20:20
    some government person. And of course, you
    could could imagine yourself how it's not
  • 20:20 - 20:24
    a good thing if you if it's possible. But
    the interesting thing here is that even
  • 20:24 - 20:28
    though Chuck is doing attack, it depends
    on your perspective. It might look like
  • 20:28 - 20:32
    attack on Alice or on Bob. But in this
    case, email won't go through Alice's
  • 20:32 - 20:38
    systems. As you can see, Chuck is sending
    e-mail directly to Bob's incoming
  • 20:38 - 20:44
    server. Now, there is a second type of
    attack that will be looked at. If we are
  • 20:44 - 20:49
    sending e-mail in other direction from Bob
    to Alice. And our customer is Alice. So we
  • 20:49 - 20:53
    are testing Alice's server. And in this
    case, we are trying, again we are Chuck.
  • 20:53 - 20:59
    We are sending e-mail. In this case,
    e-mail will go through Alice's systems. So
  • 20:59 - 21:04
    interesting question is, which is easier
    to protect. It might seem that since in
  • 21:04 - 21:07
    the second example, e-mail is actually
    going through Alice's systems, that means
  • 21:07 - 21:12
    that Alice has more power to do something,
    to do some additional checks and balances
  • 21:12 - 21:16
    and so on. But actually, as you will see
    in the future, it's easier to protect the
  • 21:16 - 21:22
    first example. So even though our customer
    is Alice, we're trying to protect Alice,
  • 21:22 - 21:27
    but it's easier to protect in practice
    this example where someone is selling,
  • 21:27 - 21:33
    sending e-mail, trying to impersonate
    Alice. Okay. Oh, yeah. That there is the
  • 21:33 - 21:38
    third example, which is if Alice is
    communicating with her colleagues inside
  • 21:38 - 21:42
    the same organization. Again, we are Chuck
    in this case. Again, we will only send the
  • 21:42 - 21:48
    e-mail to Alice's incoming server. Not to
    outgoing server. Right. So important thing
  • 21:48 - 21:54
    to note. And again, in principle, this
    third example is the easiest to notice,
  • 21:54 - 22:00
    because Alice's organization presumably
    knows that her e-mails always should come
  • 22:00 - 22:04
    from this particular outgoing server.
    Right. Like if we are sending e-mail from
  • 22:04 - 22:09
    Alice's colleague, then incoming server in
    principle should have all the power, even
  • 22:09 - 22:16
    without any standards and stuff like that.
    But in practice, sometimes actually quite
  • 22:16 - 22:24
    often there will be a specific whitelist
    for Alice's own organization. So some
  • 22:24 - 22:29
    checks won't happen if incoming server for
    Alice is receiving email, which is coming
  • 22:29 - 22:35
    from, again, Alice. And by the way,
    there's this example. We've seen that for
  • 22:35 - 22:39
    the past few years. I think it's not
    specific to Latvia. So here, for example,
  • 22:39 - 22:44
    is Canada and others,if you can see. This
    are these emails which are fake like
  • 22:44 - 22:48
    ransomware stuff. Basically, they are
    telling you that they have hacked your
  • 22:48 - 22:54
    computer or your email. In this case, and
    they have arranged all sorts of financial
  • 22:54 - 22:59
    activity or have some blackmailing you.
    And please send them the money. Your
  • 22:59 - 23:05
    money. I mean, your money in bitcoins to
    their address. So, these e-mails.
  • 23:05 - 23:09
    Interesting part about these e-mails is,
    that they are usually in order to prove to
  • 23:09 - 23:13
    you that they have access to your e-mail
    account. They are sending e-mail from your
  • 23:13 - 23:20
    address to your address. So and for many
    people, that works. So they see that
  • 23:20 - 23:23
    someone has hacked their account,
    obviously, because they've received e-mail
  • 23:23 - 23:29
    from themselves. So as you will see a bit
    later, it's actually easy to spoof such
  • 23:29 - 23:34
    e-mails if there haven't been any
    protections, haven't been put in place. So
  • 23:34 - 23:38
    the important thing, I hope that now no
    one in this audience is falling for such
  • 23:38 - 23:44
    scam. But if you have some friends or
    colleagues that have contacted you and
  • 23:44 - 23:48
    told you about such e-mails that they have
    received. But one of the things besides
  • 23:48 - 23:53
    checking the passwords is starting using
    more effective authentification on is a
  • 23:53 - 23:58
    just maybe you could tell them that they
    should contact their email administrators
  • 23:58 - 24:03
    or IT team and ask them about anti
    spoofing protection, because obviously if
  • 24:03 - 24:09
    they are able to receive such e-mail and
    it's not filtered, something is wrong.
  • 24:09 - 24:17
    Okay, and now let's see a spoofed SMTP
    conversation, so that's example similar to
  • 24:17 - 24:22
    previous one. But in this now we are
    actually Chuck. So this is sent by Chuck
  • 24:22 - 24:26
    to Bob, but we are pretending to be Alice.
    The question is, can you see the
  • 24:26 - 24:30
    difference how this is different from from
    the previous one? And it's hard to see the
  • 24:30 - 24:33
    difference because there is none
    difference. That is the same conversation.
  • 24:33 - 24:40
    So the point here is that SMTP protocol by
    itself it actually it doesn't have any
  • 24:40 - 24:44
    protection. So, yeah, you could just for
    example, if you are that guy that is
  • 24:44 - 24:50
    sending the fake ransom letters, you can
    just write down this text and just dump it
  • 24:50 - 24:56
    to telnet and it will work for many
    organizations. Not for all. And of course,
  • 24:56 - 25:01
    the email admins know this stuff, know
    that SMTP is not very reliable in this
  • 25:01 - 25:05
    regard. That's easy to spoof and so on.
    And there have been many attempts to add
  • 25:05 - 25:12
    some protection, just like ad hoc way. So
    no standards just to ransom, add some
  • 25:12 - 25:16
    additional filters and stuff into your own
    mail. And some of these protections
  • 25:16 - 25:21
    actually break RFC. If you read it, but
    who cares? Like RFC is not a sacred text
  • 25:21 - 25:26
    or it's. I absolutely approve this, for
    example. So yeah, go on. But the problem
  • 25:26 - 25:32
    is that there is not enough information.
    So if you think back here, if we are Bob
  • 25:32 - 25:35
    and we are trying to protect our systems.
    So we are Bob, some system administrator
  • 25:35 - 25:40
    probably or Bob is a sys admin and we are
    trying to add some additional rules and
  • 25:40 - 25:45
    stuff, then what actually can we do? So
    one example that I listed here is doing
  • 25:45 - 25:50
    this SMTP callback, and that means that we
    are just the when we receive e-mail from
  • 25:50 - 25:57
    Alice, we actually check does that email
    exist at all? Because many spammers, what
  • 25:57 - 26:02
    they will do, they will just send e-mail
    from non existing emails and it will work
  • 26:02 - 26:09
    by if you are just running raw SMTP
    server. So SMTP callback is basically you
  • 26:09 - 26:13
    are when you are receiving email from, for
    example. Alice, you are trying. You are
  • 26:13 - 26:17
    running, spawning a separate process which
    will try to connect back to Alice, etc.
  • 26:17 - 26:24
    And it will try to send email her. If a
    server says that. Yeah, that's okay. Such
  • 26:24 - 26:28
    email exists and so on. You are not like,
    you actually stop the conversation. You
  • 26:28 - 26:31
    don't continue with sending email, but
    then your system can automatically find
  • 26:31 - 26:37
    that actually this e-mail really exists.
    So another way to do this is through
  • 26:37 - 26:42
    checking this "Hello". And this is the
    first line and the first line, it's,
  • 26:42 - 26:48
    normally it should tell you the hostname
    of the server that is sending email.
  • 26:48 - 26:53
    Interesting part. So according to RFC
    again, you shouldn't check it that you
  • 26:53 - 26:57
    shouldn't verify. And if it doesn't, if
    it's a random thing, you should accept
  • 26:57 - 27:05
    email still. But what many servers will do
    is they will try to verify that. First of
  • 27:05 - 27:08
    all, this hostname, which you are telling
    that you have this hostname. First of all,
  • 27:08 - 27:13
    that it really points to the same IP
    address and then they do the opposite. So
  • 27:13 - 27:19
    they will take IP address and try to run a
    reverse DNS PTR query and they will try to
  • 27:19 - 27:23
    find whether that IP address really
    responds to this hostname. So again, as a
  • 27:23 - 27:27
    penetration testers we should be aware of
    these protections, ad hoc protections,
  • 27:27 - 27:31
    because they are if you don't know about
    them, you will try running something and
  • 27:31 - 27:35
    it won't work for you. But they are easy
    if you are aware of them and if you have
  • 27:35 - 27:40
    to identify that this organization uses
    them. They are easy to bypass so that they
  • 27:40 - 27:45
    don't offer good protection. They are
    meant to protect from mass abuse from
  • 27:45 - 27:53
    spam. OK, so SMTP, as we've seen, by
    itself does not do does not offer any
  • 27:53 - 27:59
    protection. So which additions to the
    protocol actually can we use to protect
  • 27:59 - 28:07
    ourselves? One of such protocols is SPF.
    And what SPF does is it's trying to be
  • 28:07 - 28:13
    like mirror MX system. MX system is the
    one which basically Alice can use to
  • 28:13 - 28:18
    Alice's server can use to automatically
    find the server that belongs to Bob and
  • 28:18 - 28:25
    its incoming server. So. SPF is the
    opposite of that. So that's an idea is
  • 28:25 - 28:30
    here to run the system automatically on
    the Bob's incoming server. And now when
  • 28:30 - 28:36
    Bob receives the e-mail, they can run
    again DNS query and they can find what IP
  • 28:36 - 28:42
    addresses actually should belong to
    Alice's outgoing server. Right. So it's I
  • 28:42 - 28:46
    think it's easy to understand it's
    actually a meaningful way. It sounds
  • 28:46 - 28:53
    meaningful addition. And the one field
    that is checked in this example is this
  • 28:53 - 28:59
    envelope sender. OK. And here's an example
    of minimal SPF syntax and the as we can
  • 28:59 - 29:05
    see. I think it's easy to understand, even
    if you don't know the syntax is it lists
  • 29:05 - 29:08
    IP address, which is IP, should be IP
    address of outgoing server, legitimate
  • 29:08 - 29:13
    outgoing server. And then it says this
    "-all" which again, is easy to understand.
  • 29:13 - 29:19
    In this case, it means that that's the
    only one. So if you receive a message,
  • 29:19 - 29:23
    message comes from this IP address. That's
    cool. I accept it. If it's something else,
  • 29:23 - 29:27
    then just drop it. And there are multiple
    ways to specify the IP address. You could
  • 29:27 - 29:32
    just specify the IP address. You could
    specify IP subnet, you could specify DNS
  • 29:32 - 29:37
    hostname. So it's just for admin. So
    basically for a penetration test, it
  • 29:37 - 29:45
    doesn't do much different, for admins it's
    just easier to maintain these systems. And
  • 29:45 - 29:50
    then there are these qualifiers,
    qualifiers. This is what's something which
  • 29:50 - 29:56
    you put before the methods. For example,
    here in this example, IPv4 before doesn't
  • 29:56 - 30:00
    have any qualifier. There's no plus or
    minus or something. That's because plus is
  • 30:00 - 30:04
    assumed by default. So by default,
    everything that is listed in SPF record
  • 30:04 - 30:13
    will should the match some legitimate SMTP
    server, outgoing server. However. There
  • 30:13 - 30:16
    are other options you could use minus
    which is fail. And that means if something
  • 30:16 - 30:20
    matches this record, for example, minus
    all is the one which is the most often
  • 30:20 - 30:27
    used, it means if it matches this one, so
    that's usually the last one, then please
  • 30:27 - 30:32
    drop the mail. It's not real. It's it's
    fake mail. And then there's this third
  • 30:32 - 30:37
    option, which is softfail, and that's
    meant for testing period. So when you are
  • 30:37 - 30:43
    just starting to implement SPF, there
    might be some. So the problem is that you
  • 30:43 - 30:48
    might forget, for example, to add some
    SMTP servers. So because you haven't done
  • 30:48 - 30:53
    it before, maybe you think you have only
    one SMTP actually outgoing server. But in
  • 30:53 - 30:56
    fact, you have multiple of them or
    multiple ways to send e-mail. So in that
  • 30:56 - 31:04
    case, if you were to start set that SPF
    record with "fail" strong policy, then
  • 31:04 - 31:07
    your users won't be able to send the
    message anymore. So that's why testing is
  • 31:07 - 31:13
    good. However. Here are some other
    examples, a bit more complicated. One of
  • 31:13 - 31:16
    them is was include. So instead of
    defining the policy yourself because
  • 31:16 - 31:19
    you're using third party, for example,
    Google in this example, and then you will
  • 31:19 - 31:25
    just include whatever Google has
    published. And the interesting thing is
  • 31:25 - 31:32
    this usage of SPF. If we just if we just
    look at the amount of domains that have
  • 31:32 - 31:37
    defined some sort of policy, that the
    number looks pretty okay. I guess that's
  • 31:37 - 31:42
    for example for most popular domains
    that's around 70 percent. But the problem
  • 31:42 - 31:46
    is that the majority of them are either
    poorly configured or they just use the
  • 31:46 - 31:52
    softfail option. And what softfail
    practically does is nothing. You still can
  • 31:52 - 31:57
    even if there is policy with softfail, you
    can in most cases you can spoof your email
  • 31:57 - 32:01
    and it will still go because the recipient
    side will think that it's just in the
  • 32:01 - 32:08
    testing mode. You shouldn't drop e-mail
    automatically. Yeah. So. Actually, the
  • 32:08 - 32:14
    percentage isn't that great. However, the
    most important thing for us as penetration
  • 32:14 - 32:18
    testers is to understand. So what do we do
    when we see this SPF. That means that now
  • 32:18 - 32:25
    we can't spoof mail and. No, it does not.
    That it's game over for us. We can do some
  • 32:25 - 32:30
    stuff. So first of all, is this softfail
    that I mentioned. And that's basically you
  • 32:30 - 32:34
    have some rules, rules, rules, and then in
    the end, you are putting typically just
  • 32:34 - 32:41
    this softfail at all. So if we as a
    penetration testers will try spoofing from
  • 32:41 - 32:46
    some unknown IP address that hasn't been
    listed in the previous rules. Then do
  • 32:46 - 32:52
    nothing. Do nothing. I mean, don't drop
    email. That is good for us, right? That
  • 32:52 - 32:57
    means that we can actually spoof just in
    the same old way and it will mostly go. So
  • 32:57 - 33:02
    the one great one note here is that some
    systems are you are not using just this
  • 33:02 - 33:07
    binary classification, whether something
    is good or bad, but they are trying to run
  • 33:07 - 33:11
    some scoring. And then it might be that
    even if you have this soft fail, they
  • 33:11 - 33:16
    won't automatically drop your e-mail, but
    maybe they will add some like suspicious
  • 33:16 - 33:23
    level to it. But important thing is that
    it's not automatically a game over.
  • 33:23 - 33:30
    Another thing is this include. So include
    is it very convenient when you are using
  • 33:30 - 33:36
    third parties. But the problem is that
    it's not what it sounds to some people, at
  • 33:36 - 33:43
    least even in the standard, it mentions
    that it was a poorly chosen name. And the
  • 33:43 - 33:48
    reason for that is that it's not a macro.
    So to understand what's happening when
  • 33:48 - 33:53
    this included, you shouldn't just copy
    paste everything from inside recursively
  • 33:53 - 33:58
    to the top level. It's not how it works.
    It will try running all the checks inside
  • 33:58 - 34:05
    this include. But then if it fails, it
    won't automatically drop the message. It
  • 34:05 - 34:10
    will go to the one level top and it will
    try running the other rules. So the
  • 34:10 - 34:15
    problem with that is that two cases that
    are the most common is that either if you
  • 34:15 - 34:21
    just forget to add this minus all to , or
    your system administrator who has
  • 34:21 - 34:26
    forgotten to do that. In that case, even
    if they include has minus all, it won't
  • 34:26 - 34:34
    work because I mean, it would because when
    the recipient will be checking it minus
  • 34:34 - 34:40
    all inside include does not mean the same
    as it does on the top level. And the
  • 34:40 - 34:44
    second would be if they have added all but
    did softfail all. And some admins might
  • 34:44 - 34:48
    think that. But that's okay because I'm
    including GMail and GMail has this hard
  • 34:48 - 34:54
    fail. Doesn't work that way. And then one,
    which actually is I think maybe the most
  • 34:54 - 35:00
    common case, is that something often you
    actually see this type of SPF records, but
  • 35:00 - 35:04
    there is lots of stuff inside there is IP
    addresses. There are these A records,
  • 35:04 - 35:08
    there is a MX. There is a pointer.
    Basically, everything that the admins
  • 35:08 - 35:13
    could think of and the reason is that the
    most commonly, they are just not sure how
  • 35:13 - 35:17
    it works. They're not sure what they
    should put inside. So, for example, one
  • 35:17 - 35:25
    thing that the point that out is if there
    is a MX record inside the SPF, most
  • 35:25 - 35:28
    commonly most organizations, unless they
    are very small and just have one server,
  • 35:28 - 35:31
    they will have different servers,
    different IP addresses for outgoing mail
  • 35:31 - 35:34
    and for incoming mail. That means there is
    no practical for this organization,here is
  • 35:34 - 35:41
    no practical reason to include MX into SPF
    because no, no mail should go out through
  • 35:41 - 35:46
    their incoming mail server. And another
    case might be that the admins understand
  • 35:46 - 35:51
    how it works, but it's really, truly their
    architecture is really messy and they are
  • 35:51 - 35:56
    sending emails from many, many different
    points, which is good for penetration
  • 35:56 - 36:03
    testers. That means that they are not well
    organized. OK. And then there's another
  • 36:03 - 36:09
    flaw, which is that granularity isn't very
    well suited. So the only thing you can.
  • 36:09 - 36:14
    There are multiple this record types. But
    all they do basically are resolve the IP
  • 36:14 - 36:20
    address. But the as you can imagine, in
    many cases, IP is not linked just to mail
  • 36:20 - 36:24
    server. So on one IP, there might be mail
    server and web server or database or
  • 36:24 - 36:28
    something else. And that means that as a
    penetration tester, you can exploit this
  • 36:28 - 36:32
    something else. Not mail server itself,
    because mailserver usually is pretty like
  • 36:32 - 36:37
    low key. There's not many vulnerabilities
    there. You just patch them and that's it.
  • 36:37 - 36:43
    But those other systems, for example, web,
    it's easy to exploit. In most cases. So
  • 36:43 - 36:47
    then you can elevate like in some sort
    elevate privileges by gaining access
  • 36:47 - 36:51
    through some other server on that IP
    address or IP range. You can start sending
  • 36:51 - 37:00
    mails. They will pass all SPF filters. OK.
    So one example is shared hosting, which is
  • 37:00 - 37:05
    the very common case and the problem with
    shared hosting is that. In this case.
  • 37:05 - 37:10
    Okay. You have IP address of SMTP server.
    Maybe that's server only used for sending
  • 37:10 - 37:16
    mails. But the server itself works not
    just for you. It works for many domains,
  • 37:16 - 37:19
    maybe hundreds of thousand domains. That
    means as an attacker, again, you can
  • 37:19 - 37:24
    exploit at least one of them, or for
    shared hosting you can just buy. You can
  • 37:24 - 37:27
    become a customer of that shared hosting.
    You don't even need to exploit anything.
  • 37:27 - 37:32
    And then you can potentially start sending
    email, which will look good as far as SPF
  • 37:32 - 37:38
    is concerned, just like their own. So. And
    the another one is this checking wrong
  • 37:38 - 37:45
    identifier. And this is probably the
    worst, worst problem with SPF. It is that,
  • 37:45 - 37:50
    as I mentioned before, the one there are
    at least two identifiers. Typically
  • 37:50 - 37:54
    envelope sender, the outer one, which
    lists the sender, and then there is
  • 37:54 - 37:59
    internal one, which is usually "from"
    header. But out of those two SPF only
  • 37:59 - 38:03
    checks, if SPF is the only technology that
    you are using, SPF only checks the first
  • 38:03 - 38:09
    one: envelope sender. And as I mentioned,
    in most cases, actual users that will
  • 38:09 - 38:13
    receive the mail, they won't see envelope
    senders. They will see this and this other
  • 38:13 - 38:18
    one "from" for example, or one of the
    other headers they mention. So this
  • 38:18 - 38:23
    behavior is fixed actually by DMARC, which
    is the technology that I mentioned. But
  • 38:23 - 38:27
    the majority of SPF installations, domains
    that are using SPF do not have DMARC, so
  • 38:27 - 38:31
    they are not protected by this. So even if
    their SPF is completely great for
  • 38:31 - 38:37
    attacker, it means that you only need to,
    what you need to do to pass SPF is a to
  • 38:37 - 38:40
    set envelope sender to something else. For
    example, your own controlled address,
  • 38:40 - 38:49
    which will pass all SPF checks. But then
    inside the "from" you can show the header
  • 38:49 - 38:57
    that will match this organization that you
    want to pretend to be. Okay. So then there
  • 38:57 - 39:02
    is another technology which is supposed to
    fix this and it's DKIM. As we have seen,
  • 39:02 - 39:11
    SPF is not enough. So DKIM. Sorry, the
    wrong letters, Domainkeys identified mail.
  • 39:11 - 39:15
    That's the DKIM and you don't need to
    remember the long name, just the short
  • 39:15 - 39:20
    name. And what it does, basically, it uses
    cryptography, which is nice, right? It's
  • 39:20 - 39:25
    math. It's hard to break for attackers.
    And what it does is it signs every mail so
  • 39:25 - 39:30
    every mail that is going out through the
    DKIM enabled server will get signature,
  • 39:30 - 39:35
    which you can, as a recipient, you can
    cryptographically verify. So as you can
  • 39:35 - 39:40
    see, how it looks is actually pretty hard
    to see because it's not meant to be
  • 39:40 - 39:44
    processed by humans. It's cryptography.
    It's meant to be processed by computers.
  • 39:44 - 39:48
    But the important part here is basically
    the yellow stuff is this cryptographic
  • 39:48 - 39:56
    signature. But the green part is what's
    called domain identifier. And the red part
  • 39:56 - 40:02
    is what's called. I don't remember how
    it's called laughs. But basically it's
  • 40:02 - 40:07
    idea is that you can have multiple keys
    for your organization, for example, your
  • 40:07 - 40:12
    organization might be sending mails from
    your original SMTP server, then you might
  • 40:12 - 40:18
    have a backup one or you might have might
    be sending some messages from Google or
  • 40:18 - 40:22
    some marketing campaign and so on. And
    then each of them might have different
  • 40:22 - 40:27
    "red", this parameter. The problem is and
    then the recipient will need to run DNS
  • 40:27 - 40:33
    query, which is the second example using
    this combination of green and red one. And
  • 40:33 - 40:37
    then they will get the public key and they
    can use this public key to verify the
  • 40:37 - 40:44
    signature. So it's sounds really nice. The
    problem here is no, another problem yet.
  • 40:44 - 40:49
    So how to use it? I think it's easy if you
    understand the public cryptography. So on
  • 40:49 - 40:52
    the sender side, you need to first
    generate public and private keypairr. Then
  • 40:52 - 40:56
    you publish the public part in the DNS.
    Then you use private key to sign each
  • 40:56 - 41:00
    message. Now recipient does sort of the
    opposite. They once they receive the
  • 41:00 - 41:04
    email, they figure out from this red and
    green part they figured out the correct
  • 41:04 - 41:09
    DNS record to run, run it, get the public
    key and then compare whether this public
  • 41:09 - 41:13
    key corresponds to the signature. So it
    sounds really nice, right? What's the
  • 41:13 - 41:19
    problem? So customers. Selectors, that's
    the name. So the problem with that is that
  • 41:19 - 41:27
    the selectors there might be multiple
    selectors as a DKIM when you are doing
  • 41:27 - 41:32
    configuration, you can select as many of
    this custom selectors as you want, and the
  • 41:32 - 41:37
    recipient doesn't know whether you
    actually should have used a selector and
  • 41:37 - 41:42
    what selector you should have used. So the
    problem is that while, if we are talking
  • 41:42 - 41:49
    just about the vanilla DKIM, modifying
    existing signature is hard for penetration
  • 41:49 - 41:53
    tester or for an attacker. But it's easy
    to just remove it because if you have
  • 41:53 - 41:58
    removed DKIM at all the header, the
    recipient doesn't know that it should have
  • 41:58 - 42:04
    been there because in order to check, they
    need to. So here, for example, in order to
  • 42:04 - 42:09
    check the signature, I need to know this
    green part. This domain identifier and the
  • 42:09 - 42:15
    selector which are part of this header.
    Right. So that's a huge problem. And that
  • 42:15 - 42:21
    means that. Yeah. That means that we can
    actually while we can't spoof DKIM itself,
  • 42:21 - 42:27
    we can just trim DKIM, send the message
    without it. And if the DKIM was the only
  • 42:27 - 42:31
    thing which protected this system, it will
    work. So it might not get the green
  • 42:31 - 42:37
    checkmark or whatever, but it will get to
    the recipient. So. And another thing is
  • 42:37 - 42:43
    this domain selector. Why do we even need
    to set that? Because the best practice, of
  • 42:43 - 42:48
    course, is that you have envelope sender
    equal to "from" header equal to this DKIM
  • 42:48 - 42:52
    domain selector. Right. So if you are if I
    am sending from Alice, then all three
  • 42:52 - 42:59
    should be Alice.org or whatever. The
    problem is that it's not mentioned in RFC
  • 42:59 - 43:04
    that that should be the case. So what
    exactly happens when it is not that way?
  • 43:04 - 43:10
    For example, on the right side there is
    some real domain which was using Gmail,
  • 43:10 - 43:17
    Google Apps, Google suite, and in that case
    the default by default Google suite will
  • 43:17 - 43:22
    sign all messages. But if you do not do
    your own configuration, it will sign them
  • 43:22 - 43:28
    with domain it controls, which is this
    "gappssmtp". And what it means is that
  • 43:28 - 43:33
    although technically something has been
    signed with DKIM, it wasn't signed in the
  • 43:33 - 43:36
    way that you can trace back to your
    organisation. It's something completely
  • 43:36 - 43:40
    else. What exactly recipient should do in
    that case? Should they just ignore it?
  • 43:40 - 43:44
    Should they reject the message or
    something? So the correct way would be not
  • 43:44 - 43:49
    to reject it, but just consider it not
    valid, at least not not a valid DKIM, but
  • 43:49 - 43:54
    it actually depends. So some validators
    will just see any DKIM, will validate it
  • 43:54 - 44:01
    and will say that's cool that matches RFC.
    So but now the interesting part. Modifying
  • 44:01 - 44:07
    DKIM, which I don't have time for. But the
    idea is that in some cases this is not
  • 44:07 - 44:11
    always but sometimes you actually can
    modify. The easiest part to modify in the
  • 44:11 - 44:17
    messages are headers because DKIM, since
    it's placed in headers itself, it does not
  • 44:17 - 44:21
    automatically sign old headers. There's
    like a chicken and egg problem. So by
  • 44:21 - 44:26
    default it only signs one or two headers
    and you can specify more headers that need
  • 44:26 - 44:31
    to be signed, but it doesn't happen
    automatically. So the easy part for
  • 44:31 - 44:36
    attacker is to add another header. If
    that's somehow helps you in your like
  • 44:36 - 44:40
    plan, then that's easy to do. You just add
    another header. An interesting part is,
  • 44:40 - 44:44
    although the RFC, as I mentioned before,
    mentions that some headers such as
  • 44:44 - 44:49
    "subject" or "from" should only be present
    in one copy. Actually you could add more
  • 44:49 - 44:53
    than one for example "from" header, and
    what happens in that case is pretty
  • 44:53 - 44:59
    interesting. DKIM will match if you have
    told to DKIM that "from" header should be,
  • 44:59 - 45:04
    for example, signed, then it will match
    and sign first "from" header from the
  • 45:04 - 45:11
    bottom. But quite a lot of software in our
    software email clients will actually only
  • 45:11 - 45:17
    display to the user first from the other
    side, from the up side. So what it means
  • 45:17 - 45:24
    is that the attacker can mangle or
    overwrite headers by just adding new
  • 45:24 - 45:30
    headers to the top. And the this actually
    problem is mentioned in the DKIM RFC and
  • 45:30 - 45:33
    the protection that they propose is this
    code Over-Signing or you can go and read
  • 45:33 - 45:39
    the RFC. But not everyone is doing that
    actually. And however, that only goes to
  • 45:39 - 45:45
    the headers. So sometimes that is good.
    Sometimes that's not good. Modifying
  • 45:45 - 45:49
    message body is actually much harder to
    do. Basically the naiv way do it through
  • 45:49 - 45:54
    cryptography, which we don't want to do.
    And another way is through this one
  • 45:54 - 45:58
    parameter, which is body length, and
    that's actually like questionable
  • 45:58 - 46:05
    functionality that DKIM has. Sometimes you
    can specify that the hash like. For
  • 46:05 - 46:09
    signing purposes, we shouldn't consider
    the whole body, but only first something
  • 46:09 - 46:14
    bytes. So that's actually useful in some
    cases regarding was a mailing list, but
  • 46:14 - 46:19
    for the most part that's not useful. And
    in practice, most email software does not
  • 46:19 - 46:24
    do this. If it does, then it is
    susceptible to potentially to this
  • 46:24 - 46:29
    overwriting body as well. You could add
    another mime type and then then modify
  • 46:29 - 46:34
    headers to show that different mime type
    and it will pass DKIM. So in this case, it
  • 46:34 - 46:38
    actually will show, for example, the green
    button or whatever, because DKIM, it will
  • 46:38 - 46:43
    be valid. So now there's the third
    technology, which is called DMARC. And
  • 46:43 - 46:48
    again, there is the full name, which is
    long, but in this case actually it means
  • 46:48 - 46:52
    something. There are two key words:
    reporting and conformance. Reporting is
  • 46:52 - 46:57
    the one which most admins are familiar
    with because that's how DMARC I think
  • 46:57 - 47:02
    often is being sold to them. Reporting
    means that when you have some problems in
  • 47:02 - 47:08
    this case, you actually get get to tell
    other side what to do in that case. So
  • 47:08 - 47:13
    basically you tell them to send you
    reports either once per day or every time
  • 47:13 - 47:17
    and so on. So for penetration testers,
    it's not that useful. Potentially we could
  • 47:17 - 47:21
    use that to understand what sort of
    configuration is running on the other
  • 47:21 - 47:25
    side. But the currently this functionality
    actually is not that widely implemented.
  • 47:25 - 47:30
    However, the other part conformance, it's
    actually really, really, really powerful.
  • 47:30 - 47:35
    What it does, that it corrects these major
    flaws that I mentioned in SPF and DKIM. So
  • 47:35 - 47:39
    first of all, DKIM had this massive
    problem that if you just strip down the
  • 47:39 - 47:43
    header, then the recipient has no way of
    knowing whether you whether there was
  • 47:43 - 47:49
    should have been DKIM in first place. If
    you are using DKIM alongside with DMARC
  • 47:49 - 47:55
    that fixes the problem, because DMARC
    specifies just that you have DMARC itself.
  • 47:55 - 47:59
    It means that you're automatically at
    least one of the SPF or DKIM should pass.
  • 47:59 - 48:04
    So automatically DKIM is like measure
    problem solved. The other thing that
  • 48:04 - 48:09
    changes is, it changes the semantics for
    SPF. Now, SPF, if you have both SPF and
  • 48:09 - 48:13
    DMARC, it means that SPF should be checked
    against "from" header. And as I mentioned,
  • 48:13 - 48:17
    that was the major flaw with SPF, because
    if you're using SPF itself, even, it is
  • 48:17 - 48:21
    the hard to fail mode and so on, it means
    that attackers can modify "from" headers
  • 48:21 - 48:27
    still and the recipient won't know any
    better. So a minimal example of DMARC is
  • 48:27 - 48:31
    really, really small. And I think it's
    easy to understand. You have just a DMARC
  • 48:31 - 48:37
    reject. You need to like find out the
    right place to specify. But it's easy and
  • 48:37 - 48:41
    all you have to do is create this one DNS
    record. And the benefit for that is even
  • 48:41 - 48:46
    if you don't have DKIM and DMARC, if you
    have created. Sorry if you don't have SPF
  • 48:46 - 48:51
    and DKIM, but you have created DMARC,
    effectively what it means is that this
  • 48:51 - 48:58
    domain should not send any mail because
    for recipient to consider a mail valid at
  • 48:58 - 49:02
    least SPF or DKIM should be valid as well.
    If they are not, then they can't be valid.
  • 49:02 - 49:07
    So in fact what it means is that most
    domains out there should consider enabling
  • 49:07 - 49:15
    DMARC. That's just the right thing to do.
    OK. So there are more tags. So in the
  • 49:15 - 49:22
    wild, these DMARC records might be much
    longer, but it's not of much use to
  • 49:22 - 49:26
    penetration testers. So important part
    here is again, this is this policy which
  • 49:26 - 49:31
    can be three values "none", "quarantine"
    and "reject". And if it is "quarantine",
  • 49:31 - 49:39
    that means if the, if there is a failure,
    the message should go to the spam folder.
  • 49:39 - 49:43
    If it's "reject", it should be rejected
    outright. And if it's "none", it means
  • 49:43 - 49:48
    it's in investing mode. So and this is the
    picture that I showed in before, which
  • 49:48 - 49:52
    shows that actually even though DMARC is
    really like the best technology out of
  • 49:52 - 50:00
    these three, it's not really widely used,
    unfortunately for defenders. Quite a nice
  • 50:00 - 50:05
    fact for all penetration testers out
    there. That means that you can, in fact
  • 50:05 - 50:15
    spoof most of the mails out there. Okay.
    So how do we work around it? Sorry. So.
  • 50:15 - 50:18
    What happens if actually someone has
    implemented DMARC? Does that mean that now
  • 50:18 - 50:24
    penetration testers can't do anything? You
    don't don't even need to do any research?
  • 50:24 - 50:29
    No, it doesn't. So in practice, if someone
    has implemented both DKIM and DMARC, but
  • 50:29 - 50:34
    not SPF, so they have only two of them.
    That's a really cool combination. DKIM is
  • 50:34 - 50:38
    pretty powerful and the major flaw that it
    had DMARC solves. So this combination is
  • 50:38 - 50:45
    really cool in theory. In practice, the
    problem is that in order to protect your
  • 50:45 - 50:50
    own mails, the recipient side should
    validate both DKIM and DMARC and
  • 50:50 - 50:54
    unfortunately, quite a lot of software
    still does not do that. One such software
  • 50:54 - 50:58
    is Microsoft Exchange. And even if you are
    not running Microsoft Exchange, chances
  • 50:58 - 51:02
    are good that some of the partners that
    you are communicating with are running
  • 51:02 - 51:06
    Microsoft Exchange, and by default it
    doesn't have any functionality to parse
  • 51:06 - 51:13
    DKIM. So in fact, most systems still need
    to enable SPF just for practical purposes,
  • 51:13 - 51:17
    which is good for penetration testers
    because if SPF and DMARC as enabled by
  • 51:17 - 51:22
    default together, then again that fixes
    one of the major problems with SPF, but
  • 51:22 - 51:26
    does not automatically fix other problems
    because there's not enough granularity and
  • 51:26 - 51:32
    the potential for misconfiguration. So.
    And the interesting fact is that DMARC
  • 51:32 - 51:38
    only requires that one of the other
    technologies SPF or DKIM is passed in
  • 51:38 - 51:43
    order to consider email valid. There is no
    way in DMARC, even though there are many
  • 51:43 - 51:46
    others like selectors. There is no way to
    specify that both of them should be valid
  • 51:46 - 51:50
    or that DKIM should be preferred to SPF.
    In practice, what it means is that for
  • 51:50 - 51:55
    most systems that enable all three of
    them, which is a good practical solution
  • 51:55 - 52:00
    from penetration tester side we can just
    ignore DKIM outright and just focus on SPF
  • 52:00 - 52:05
    because the SPF is the weakest link in
    this situation. Okay. So just a minute for
  • 52:05 - 52:12
    recap. I'm not sure if I have any more
    time. Not many time I have. Okay. So
  • 52:12 - 52:17
    sorry. Yeah. So one really important note
    is, when you are testing the systems,
  • 52:17 - 52:22
    consider both scenarios. So don't focus
    just on send. If you are, for example,
  • 52:22 - 52:28
    testing Alice. Alice is the organisation
    that is your customer. Don't just focus on
  • 52:28 - 52:34
    testing emails sent impersonating Alice,
    but also as the other side. Because in
  • 52:34 - 52:39
    this here you can see that it's easy to
    implement for example, SPF and DMARC
  • 52:39 - 52:44
    because for both of them only you only
    need DNS configuration. Just one record
  • 52:44 - 52:49
    per each. However actually testing them
    like well validating them properly is
  • 52:49 - 52:53
    harder. For the first you need the
    software support, you need to configure it
  • 52:53 - 52:57
    correctly as well. So in practice it might
    be that many of organisations that have
  • 52:57 - 53:02
    enabled DMARC or SPF on the DNS side for
    outgoing mails, they are not actually
  • 53:02 - 53:08
    properly validating it. Yeah. Okay. Sorry,
    I don't have time for that. So probably.
  • 53:08 - 53:16
    That's it. Sorry. Maybe some questions.
  • 53:16 - 53:25
    applause
  • 53:25 - 53:30
    Herald: Thanks, Andrew, for this nice
    talk. Sure. We have time for a couple of
  • 53:30 - 53:34
    questions. So there I already see one
    person, microphone number two.
  • 53:34 - 53:40
    M2: Hey, thanks a lot. Do you know some
    good tools to monitor DMARC reports that I
  • 53:40 - 53:44
    get sent by my recipients?
    A: Yeah. So this is a really good
  • 53:44 - 53:50
    question. We as a CERT, we are really
    suggesting everyone to enable this tool,
  • 53:50 - 53:55
    but unfortunately, as far as I know, all
    the tools that are popular on the
  • 53:55 - 54:00
    Internet, they are collecting some data on
    you. So they are using it for marketing
  • 54:00 - 54:04
    purposes, do they are not very good for
    privacy, if you are concerned about that.
  • 54:04 - 54:08
    So you need to implement something
    yourself or you need to look at some,
  • 54:08 - 54:12
    start some open source project maybe.
    Herald: OK. Microphone number one, please.
  • 54:12 - 54:16
    M1: Thank you for the good talk. Me
    myself, I would consider myself an mail
  • 54:16 - 54:24
    administrator. I sometimes get advised to
    shorten your SPF record because if it's
  • 54:24 - 54:29
    too long, it gets dropped anyway. For
    that, I sometimes get advised to drop the
  • 54:29 - 54:35
    PTR record. But in your talk, you say the
    PTR record is useful for reverse DNS
  • 54:35 - 54:40
    checking, which I find very useful as
    well. How are you about shortening your
  • 54:40 - 54:43
    SPF and how are you about the PTR record
    in general?
  • 54:43 - 54:48
    A: Well, it really depends on your
    particular use case. So it might be the
  • 54:48 - 54:51
    case that some organizations really need
    this longer SPF and there's not no way
  • 54:51 - 54:56
    around that you could do. What you could
    do is include this, include use includes
  • 54:56 - 55:01
    because they won't be they are not macros,
    so they won't get expanded. They do not
  • 55:01 - 55:08
    like your record doesn't become longer if
    you include and use many includes. But the
  • 55:08 - 55:12
    problem, which I would suggest to you is
    actually reconsider whether it's a really
  • 55:12 - 55:17
    whether you really need that many records
    if it's still long, because they're a very
  • 55:17 - 55:20
    common problem, is that unless you are
    Google or something like that, you don't
  • 55:20 - 55:27
    really need that long SPF. It's probably
    some problem with some. Yeah. So it's
  • 55:27 - 55:36
    probably an error for most organizations.
    Herald: OK. Well, very. Just briefly.
  • 55:36 - 55:40
    Number 1
    M1: On the PTI rocker record. I heard that
  • 55:40 - 55:43
    it's dropped. Not dropped from the
    standards, but it's not in the standards.
  • 55:43 - 55:49
    A: It is in the standard. No. PTR record
    by itself is if it's really your use case.
  • 55:49 - 55:54
    I don't I'm not aware that it will be
    automatically dropped somewhere. Shouldn't
  • 55:54 - 55:56
    be a problem.
    Herald: We have a couple of more
  • 55:56 - 55:59
    questions here. So number six in the very,
    very back.
  • 55:59 - 56:07
    M6: Thank you for your talk. That's not
    directly related, but even it should be
  • 56:07 - 56:14
    related. If mail server accepts because
    DKIM, DKARC and SPF, everything is fine,
  • 56:14 - 56:19
    but especially Google for a lot of
    organizations, the mail is delivered but
  • 56:19 - 56:24
    classified as spam. It means on the inbox
    of the recipient, it is not displayed.
  • 56:24 - 56:28
    Have you a solution to solve this problem
    against Google?
  • 56:28 - 56:34
    A: Yeah. OK. So I have like different
    opinions about that because one thing
  • 56:34 - 56:39
    which actually enables which we actually
    should be doing. Thank you Google. Is
  • 56:39 - 56:43
    that they are so strict because that's the
    only reason that we even have this high
  • 56:43 - 56:48
    percentage of even improperly configured
    SPF. The only reason there are 70 percent
  • 56:48 - 56:53
    websites are using SPF is because that
    they need to communicate with Google. And
  • 56:53 - 56:57
    Google won't accept your mail if it
    doesn't have even SPF on the baseline. So.
  • 56:57 - 57:04
    I actually I enjoy it as a job that I do.
    I've. I would prefer that Google does what
  • 57:04 - 57:10
    it does. But I understand the real admins
    which have this problem. Google has the
  • 57:10 - 57:15
    tool. You probably know about it. Where
    you can check what it considers about your
  • 57:15 - 57:19
    domain. So you need to consider this
    problem on a case by case basis. Quite
  • 57:19 - 57:24
    often what happens is that even though you
    have this DKIM, DMARC and so on, it's not
  • 57:24 - 57:29
    configured correctly. So that's what the
    talk was about. So you have it. You
  • 57:29 - 57:31
    probably think that you have configured it
    correctly, but there are some errors.
  • 57:31 - 57:35
    Herald: Okay, let's give priority to the
    Internet.
  • 57:35 - 57:40
    Signal Angel: We have one question from
    the Internet. Well, attempting to verify
  • 57:40 - 57:44
    and address how to handle no reply email
    addresses.
  • 57:44 - 57:50
    A: No reply, I'm sorry. Can you read it
    again, please?
  • 57:50 - 57:55
    Signal Angel: When attempting to verify an
    address, how to handle noreply Email
  • 57:55 - 58:05
    addresses.
    A: Maybe it was about the noreply header ?
  • 58:05 - 58:11
    Or not existing IP addresses ?
    Signal Angel: How to handle email. No
  • 58:11 - 58:15
    reply email adresses.
    A: I will try to get an answer to how I
  • 58:15 - 58:22
    understand it. So what often happens is
    that what often happens is that the email
  • 58:22 - 58:25
    will be sent from nonexisting addresses.
    So maybe that's what the question was. For
  • 58:25 - 58:30
    example, there is "no reply", and it's not
    the problem itself. No reply. The problem
  • 58:30 - 58:34
    is that it's not an real address. There is
    no such address. Right. And so I don't
  • 58:34 - 58:39
    have an answer for that because according
    to RFC, you should you should still accept
  • 58:39 - 58:44
    it. Practically, as I said, lots of mail
    systems already are dropping this
  • 58:44 - 58:46
    addresses if you're sending from not
    existing unless you are Google or
  • 58:46 - 58:50
    something large, so you have been put into
    whitelist. You just won't be able to do
  • 58:50 - 58:55
    that. You won't be able to send email from
    non-existing address. So if that's your
  • 58:55 - 59:00
    situation, create the address, make it
    like a remove all the email that comes
  • 59:00 - 59:04
    there, but create the real address so that
    your acceptable. If you are on the other
  • 59:04 - 59:08
    side. So you are receiving this email. It
    depends on this particular use case. So
  • 59:08 - 59:12
    just check what's going on. If you can
    contact them, contact them. If you can't
  • 59:12 - 59:16
    contact them, then you should decide what
    is the risk, if you are dropping these
  • 59:16 - 59:24
    addresses, are they important for you? So
    according to RFC you should receive and
  • 59:24 - 59:29
    process this addresses.
    Herald: Okay. Microphone number four,
  • 59:29 - 59:33
    please.
    M4: Hey, thank you for this talk. Do you
  • 59:33 - 59:41
    know about effort to solve problems with
    big email senders like online booksellers,
  • 59:41 - 59:47
    which are very great because they don't
    seem to have their own SPF records, for
  • 59:47 - 59:53
    example, in in control.
    A: Yeah. So in many cases you can just
  • 59:53 - 59:57
    contact them. So it's just the question
    that they haven't thought about it. Or
  • 59:57 - 60:02
    maybe no one told them what to do or maybe
    they don't know how to do better. Right.
  • 60:02 - 60:05
    So that's one of the parts that we as a
    CERT we are doing. If you have some some
  • 60:05 - 60:11
    this problem with some large company in
    particular country, I would suggest to
  • 60:11 - 60:14
    contact CERT. Even if it's not a
    government organization, for example, in
  • 60:14 - 60:19
    Latvia, if that will be a latvian company.
    We would do the triage. We would try to
  • 60:19 - 60:22
    try to talk to them, explain to them why
    they need to change and so on. So that's
  • 60:22 - 60:26
    maybe one option for you. But the
    practices that if something looks to you
  • 60:26 - 60:30
    as a third party, as a wrong
    configuration, that is one I couldn't
  • 60:30 - 60:34
    mention in this talk. If something isn't
    perfectly secure, it doesn't mean that
  • 60:34 - 60:39
    it's wrong. There might be actually
    business case why it should be this way.
  • 60:39 - 60:42
    Right. Because, for example, if it's a
    large I don't know, Amazon and some for
  • 60:42 - 60:47
    something like that. And if they have
    tested and they know that when they enable
  • 60:47 - 60:52
    very strict configuration, some percentage
    of their emails just doesn't come. Not
  • 60:52 - 60:56
    because of their problem, because of
    someone else's problem. Right. But then
  • 60:56 - 61:00
    there is actually a real business case
    that they they are not. It would be stupid
  • 61:00 - 61:04
    for them to enable this, you know, to
    strict configuration, knowing that it will
  • 61:04 - 61:09
    damage their business. That makes sense,
    right?
  • 61:09 - 61:13
    Herald: Okay. We are unfortunately running
    out of time for those who are on the
  • 61:13 - 61:18
    microphones. please just line up with the
    speaker next to the desk. He's gonna talk
  • 61:18 - 61:21
    to you. Perfectly sure. And.
  • 61:21 - 61:25
    applause
  • 61:25 - 61:41
    36C3 postroll
  • 61:41 - 61:53
    Subtitles created by c3subtitles.de
    in the year 2020. Join, and help us!
Title:
36C3 - Email authentication for penetration testers
Description:

more » « less
Video Language:
English
Duration:
01:01:53

English subtitles

Revisions Compare revisions