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