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