There's nothing new except forgotten old: Abusing email and defending against it

and now moving along to a wonderful world of electronic mail uh we are going to hear about vulnerabilities in DK i m d m a RC and b i Mii and I'm sure I'm going to find out whatever that is sounds very scary because I have two different email addresses both of them don't work now I know why but uh let's welcome on stage to tell us about there's nothing new except for Goten old abusing Emil and defending against it Mr [Music]

T hi uh my name is Tav I'm From Zone media uh and officially I'm a cyber security specialist but uh unofficially I'm a email Enthusiast how can be that uh short peek into how email started uh then we're going to take a look at how we call things now then we're going to speak about how to send email and how to not send email so it's going to cover a rather wide uh array of topics uh as you can see here uh the standard ecosystem is rather complex uh there's a lot of standards uh that each and every email provider kind of has to follow or should follow but it's not that simple because we have a long long

history so here's all of the standards that have been uh deprecated or uh updated and this is only a small selection there's so many more actually uh short uh overview about the terms uh first one being mua which is the male user agent that's the thing you're reading your email with uh Thunderbird Outlook mut whatever uh second one is MSA which is uh your message submission agent and that is used to uh send your email too so your mua sends your message to the MSA and then it's it gets delivered to the MTA which is mail transfer agent and uh we at Zone have our hand in like many of these uh products many people

use uh and one of the largest sources of confusion uh are all the different addresses uh each and every email has so the first one uh is the way how the server itself calls it so it gets sent during the SMTP connection uh the server introduces itself it says how it wants to be called then there's the uh mail from command which the server sends saying where the email is from uh this address is also used to uh send back uh bounces and it also has two different names uh which often get confused uh the third one is the message from this is inside the message itself after the command has been sent so one

email has two uh from addresses already uh this is also the from address you see in your mua which is your male uh client and lastly there's the sender header which uh supplements the envelope from uh in case they mismatch so you might see this in your client as on be on behalf of uh and yeah it's rarely used but for some reason that is displayed to the user and the envelope from is not uh now we get to the first uh major standard which is the SPF uh currently it has only one applying standard but the past is uh rather colorful um so the SPF record is a simple DNS record you add to your uh DNS

Zone uh the record authorizes uh the use of a relevant domain in the uh hello and mail from identities and uh it looks rather simple uh you can uh list individual IPS you can say your MX or your a record should be authorized and lastly you can also unauthorize something so you have to kind of explicitly say that everything else uh I do not authorize which is one of the first problems as well uh but unfortunately only less than half of Estonian domains are covered by SPF and uh this SPF applies to the SMTP from which is not displayed to the user uh now we get to the bad part uh first thing is SPF alone is quite a low

uh old so we have Legacy implementations that only Implement SPF so uh email server might be looking at your uh hello or your mail from which is not the one that's actually displayed to the user another issue is shared environments because uh uh SPF boils down to IP addresses and those are really often shared uh they are shared in environments such as shared hosting but also uh Office 365 uh proof point and so on and so forth uh third issue is maintenance because uh adding This Record you're authorizing an IP uh now if you you stop using a vendor people forget to remove those IPS so you have SPF records that contain uh either IP addresses that have

been long reallocated or just including domains that are no longer registered so yeah this has become a real problem and lastly as I mentioned before it applies to the SMTP from and hello uh mostly to the first part and as this is not displayed to the user implement a so only take a look at SPF do not protect the user from uh fores uh but it cannot be ignored because we have those uh Legacy implementations we still need to uh authorize our IPS for those reasons so uh as a if you're trying to implement it you should try to keep the scope as minimal as possible use dedicated IPS where possible so if you're a vendor such as mail gun or uh

uh chimp allows you to use dedicated IPS uh document the reason behind the records content if you just authorize a vendor and you don't know what that IP is nobody's ever going to remove it thinking it will break everything uh also you can use subdomains to send your email so if you use a vendor you can give them the subdomain let them send under from that sub domain you can authorize uh just that one vendor it kind of makes the record easier it kind of makes the uh management easier also protect your Park domains so if you're not using say your type of domain your register to protect your company uh protect it with the SPF because

otherwise someone could take the domain and use it to send a fishing email you try to prevent uh second part is uh te which is uh just signing email uh now this is bit better this is uh a few years uh near uh and it permits you to authorize um domain like you you can take your domain use your uh key pair to sign a message and that domain identity gets assigned to that message uh so you do not have to use the same domain to sign your email but you should because that will be checked by other things later and there's a strong push in the industry industry to uh just allow authenticated email so uh Gmail has recently really

ramped up their requirement to have either SPF or uh te teim so again shared environments uh are a problem because you might be in uh in situations where one vendor is signing email for a lot of domains and if their uh authentication or just system is not uh uh isolated enough you can just get your email signed that is should not get signed the standard itself is a bit too vague so implementations differ in ways that we would not like them to differ uh the third issue is that uh you have to explicitly specify uh that you have signed something that does not exist this is a really annoying concept because it's really difficult to predict

what you don't want to be add add to your email so instead of just signing what has been included so this allows uh plenty of issues you will see later uh fourth issue is that there's no uh expiration by default that was added later that the implementation uh is rather poor in the uh ecosystem and uh lastly uh there's a lot of Legacy signatures out there using outdated uh crypto and the m ation to better and newer algorithms is uh hindered by the same Legacy implementations uh but again uh vendors such as Google for some reason do not support the elliptic uh curve uh signatures uh so now we get to the first example of uh bad Key Management we have

a vendor that has reused the same key to sign uh I guess bills for for uh many different domains and if you just take a quick look at the zone you can just uh look up the record and you can see which ones are sharing the same key this will uh become a problem uh later on um uh one of the most recent examples is this summer we had proofo and Echo spoofing uh where uh proofo customers uh where impersonated by malicious actors uh their domains were used to sign uh fishing emails a lot of credit card details were stolen uh and the comment uh proof Point released about the incident is also kind of interesting because they're saying

that they have gone into Great Lengths to raise awareness and uh get them to correctly configure their systems but for some reason uh this misconfiguration is the default and I do not see how the to Concepts uh go together and they blame them blame the customer in then um yeah again do not reuse Keys between your domains and customers uh this will cause a lot of trouble uh and force key lifetimes so if you do uh set up uh teim you should actually write down that you should rotate it like once a year or something because you do not want to send emails that are signed and if you check them 10 years later they

are still signed because things get outdated Keys get stolen you do not want to keep them in your DNS uh try to update your uh deim assessor which is the part that checks the signatures because there have been changes to uh better enforce uh the standards and uh do not use the length tag we will get to this later uh again you can use subdomains to limit blast radius uh just recently we had a FBI uh web server hacked which uh could send email uh and those emails were signed with their uh nice key but uh in this case they just sent a few emails to warn about the danger but uh if you combine this with the recently really

often uh found scam for uh people are scared into I don't know what the end goal is probably stealing money or something uh then you can see how a combination of these two can end up really nasty uh third one DeMark uh currently one applying standard but a few additions again uh this one uh finally applies to the from madress that you as a user actually see in your client and uh it's kind of uh annoying because uh Demar uh its deployment is much much worse than it is for even SPF for example and uh yeah you can specify a policy that gets applied to the letters based on the uh SPF and deim alignment

and that alignment is checked against yeah the right uh from madress so yeah uh solves a bunch of problems for us and and uh yeah prevents many forg forges uh and it can be deployed uh piece by piece you can uh set a percentage of emails that you're uh should be applied uh the policy so that's really nice but uh it is as strong as the weakest link so if your SPF or uh theim implementation is poor uh you will still pass D mark and the second problem is that uh you can publish a policy that does ABS absolutely nothing you can say the policy is none and uh that will just result in I guess a compliance check

mark that you have a dmar record but it doesn't do anything and actually the opposite uh you might be authorizing more emails because without the Demar record the uh assumption is that you do not know anything about Demar and we should apply just the SPF but if you say in Demar that the policy is nothing then you're allowing more for juries and uh last statistics show that the implementation in Estonia is less than 25% which is really poor uh now we're getting to the first uh uh Legacy problem I guess the ltag is was in initially intended for increasing robustness of the signatures after they pass through uh some relays such as mailing lists or

like security gateways uh and the airc after this one sentence contains four other sentences how using the length tag is a bad idea so it's not that hindsight is 2020 no there receiv was written and it was a bad idea since the start so for some reason uh 16 years have passed and we're still using it this is a recent example about domains that have used it in the last UH 60 days so you will see how this is a problem uh next uh in this case we have a letter from DHL uh you can see how actually one of the SPF checks already fails this is because this is my forgery already I have uh taken the DHL letter I have

resent it and SPF has not passed but it was accepted by Gmail because the signature was valid and the signature in this case has a length flag you can see the highlighted in red we can also see the culprit here what added the bad signature and yeah that's also highlighted so if you have iron Port appliances you should really make sure you disable this feat feature uh this is the example how it ended up so we took the nice DHL uh delivery notice that my uh packages on the way and in this case I just replaced it with a simple sentence but I might as well have added another login page or something that you need to pay like five

years to get your package or something and it would have content this nice blue check mark everything would have uh looked really authentic and yeah this for passes the check it gives it the DeMark pass which in turn gives it the Bimi pass and it's a really juicy result for a fish so if we go back here you can see how forging these letters can be really devastating for some but yeah uh now we're getting to the Bimi which was mentioned briefly uh in the previous slide this is still a draft uh so it's not finalized it's going to change a bit uh pimi which is uh short for brand indicators for message identification it permits domain owners

to coord ordinate with male user agents to just uh display a logo you like you could see in the previous slide that nice blue check mark makes it just a bit clearer to the user that the email is legit uh but again deployment of uh be as it depends on Demar is quite bad this is a global statistics and you can see like globally uh around 3,000 domains actually have working Pim uh now we're getting to the forward forwarding part uh it's a really common use case there are a lot of mailing lists there are a lot of uh security appliances there are just users that want to uh send their email somewhere else so for that reason we have the SRS

which is the sender rewriting scheme which allows us to just rewrite the uh SMTP from uh just so that the letters would pass uh SPF and uh this carries the penalty that the from address will look nasty uh but we have a more recent addition which is the arc which is authenticated received chain this allows us to sign each step in the chain of uh sending an email and in theory it should allow us to like go backwards in the like chain of uh receival and very verify that everything was okay if you trust the uh signature these are really uh similar to uh deim signatures but uh it there's not only a single solution to signing messages so

the first and uh most common one might be asime which is uh quite old again and uh it just uses uh your uh really standard uh x509 certificates and Casa so just a uh pki you can use to sign your email um just recently in addition to just uh the technical Parts uh there have been recent changes to the policy side of things so uh the CA and browser Forum has a SM work group that uh zone is also part of as an observer and uh yeah there has been a recent Baseline that the ca have to follow in order to issue smim certificates this allows you to sign your email and see a nice green check

mark in supported clients uh and technically it's quite simple uh you have a you add a respective content type header you specify the Mema type you specify your algorithm and the boundary and uh many clients also include this message in the Raw uh header uh section and this is basically that's uh it's not really complex in that sense but it really reminds me uh this meme where yeah we're going to say this is a signed message and yeah uh unfortunately yeah for many this is the extent of validation they can do but uh smime also has a few problems uh for a really long time priori where elsewhere so the M Baseline is one of

the first things in that that aspect in recent times and before that it was kind of Forgotten and other Technologies were focused on and the same uh Baseline should allow us at some point to uh have something like Acme for email so your email client can actually fetch you a certificate to sign messages with and uh the same with the the game we have smim has the same issue that the mail user agents are not actually really forced to display only the signed parts and uh when uh the length tag allowed replacing the message content uh in sme's case uh you as a user might be uh signing something like the subject or uh the from address or whatever but the

male user agent might pick the unsigned version of the same header because you can have many of the same in the same message uh signing itself is quite doable uh you only need your own key key pair and you can use it to sign your outgoing messages you do not need the receivers publicly or anything like that but clients are a bit buggy and you will see why uh soon but as MIM itself has rather widespread support uh things like even Gmail supported even the public version you don't have to be a git uh customer uh Outlook Thunderbird uh Apple Mail a lot of clients support it there is ongoing work to improve it so uh yeah

it's definitely a tech that has regained its popularity in some aspects but uh one of the potential problems with implementing Sim is that it also allows encryption but uh yeah the thing with encrypted uh emails is that you're either going to have to keep your key for a really long time which is usually not that great of an idea and uh it's failure prone but uh again I think this might actually be a benefit like as a company you probably do not want to keep all of your uh emails for like 10 years you probably shouldn't be keeping them for that long for gdpr reasons and uh one of the last benefits is that it is

intended for humans unlike SPF or uh other Tech before it those are not really meant for humans like signing stuff that isn't displayed yeah so SM in that case is better uh one of the vulnerabilities I found in Apple Mail uh just recently was that uh in certain cases you might click that nice uh blue uh padlock icon you can uh see it yeah must be enabled you can see how the uh hover text says that yeah if you click on this you will turn off the encryption but yeah then you press the send button and the email ends up unencrypted and uh depending on your email client configuration uh this can end up in like

you leaking the entire previous past conversation you had with that recipient and you can see how that is bad for a thing that says I'm now going to encrypt your reply and yeah it was fixed uh I think six months ago finally it took them a year uh but some of you might say what about pgp uh well uh first thing I actually looked into uh was double signing because uh in theory there are nothing nothing is really stopping you from adding two signatures to the same email but uh in practice U none of the clients really accepted uh messages like that because they expect one signature and it has to be uh from the one signing system

so to say and this is really unfortunate because uh you could uh kind of you would have less trade-offs if you could double sign using two systems so the recipient can just pick the one that they like more and you get a larger coverage in email clients but yeah I can't see neither ecosystem actually wanting to cooperate with the other one to allow this so it's probably going to remain a pipe tream uh but it is much less usable than SMI because the tooling um it has gotten really obsolete we have one major uh implementation that everyone basically uses uh other uh implementations kind of have to follow them instead of uh being able to uh move

forward so in that in that aspect uh bgp is kind of being uh really hindered by the past decisions that have been made and uh this results in like crypto that is not really that up toate as it should be we uh still using Primitives that are widely considered uh poor uh like for example PK pkcs one version 1.5 padding for signatures and um in 2000 2006 uh researchers said that uh uh it's really easy to implement insecurely and this has been the case in in a lot of uh uh recent implementations as well so uh yeah but you're forced to use it there is no option to use something more modern like RSA PSS uh yeah uh but it it's not only

about the letters themselves besides the letters you also have uh the transport encryption between either your uh mua or your uh mtas and for those we have two uh major Technologies one of them being MTS other one being Dan but first I'm going to touch upon start TLS uh start TLS is by all modern uh standards absolutely garbage because we're mixing upon uh mixing two different uh types of uh actions we're mixing in Secure Communications with the secure ones this has resulted in multiple different different vulnerabilities where uh either extra commands can be injected into the encrypted uh communication or uh it otherwise uh fails uh or is impacted by downgrade attacks so in that sense you

should definitely try to switch to implicit TLS it's available in basically all uh modern clients this means that uh TLS connection is straight up established everything starts up encrypted remains encrypted nothing can get injected and you're not exposing like uh unencrypted uh command interface to the uh world or something and um uh one of the problems here is though that many implementations uh call it SSL for some reason instead of uh a mix of TLS or SSL uh so SSL was the last version was deprecated in 2006 or 16 it doesn't matter really deprecated but the terms are old so you find might find TLS under the label SSL um now we're getting to MTA

SDS yeah uh MTA SS is a real relatively recent Edition uh it was uh standardized in 20 2016 uh when a DNS record uh exists saying that there's an m T SDS policy then the MTA fetches a policy document uh served over https from your uh web server it contains the version the mode uh your mx's and the max age uh the MX is the one that uh is going to be the one that the encryption is forced upon so if you say enforce uh the communication to zone mx. is going to be encrypted and the max age specifies how long an MTA should keep this policy uh like in its cash or whatever so yeah in

this case that's one day it's really easy to deplay uh it's supported by many different vendors uh one of the biggest ones being Google but uh we also supported uh for outgoing email and uh yeah it's it's not hard to deploy you can do it today basically and there's no downside unless you're t implementation is somehow uh weird uh the second one being t uh this specifies how dlsa records uh also DNS records can be added to your dnsx signed Zone to validate the DLS connections usually it's a public key of your uh server but in this case dlsa um and Dane uh has a few trade-offs which is that it depends on the existence of DNS SEC uh

DNS SEC is also like in Estonia it's quite common because uh there's a common implementation that supports it but in other cases it's rarely supported and in those cases uh it kind of fails open and uh yeah this is recent documentation from yeah Microsoft and you can see how all of the dark green squares are kind of falling open yeah and there's only one path that results in an actually secure connection uh as it should in the case of MTA SDS it's a bit more straightforward and less failure prone uh but the current state of Transport encryption is also kind of depressing because uh only MTA SDS and Dane can actually protect against an active attacker because uh email itself

is kind of so much Legacy so yeah this was not a focus when email servers were set up uh but it is a focus now uh here's a small list of uh mail servers I found uh that have no uh valid certificate and I think this should raise a few eyebrows uh because I would assum assume that if I write to my hospital or something that the letter will arrive there uh at least transport encrypted but in these cases uh that cannot be Thea case and that's even without MTA SDS uh in the future um there's a high likelihood that uh deim will also uh be changed in some aspects uh I expect that the length tag might get uh

either deprecated or uh operations notice uh published uh but also we will see an increase in dmar enforcement so if you do not have a dmar record uh then you might get your uh email is just rejected uh then there's also Bimi and as it's still a draft uh it's it's very likely that uh we will see changes that either uh alter how uh male user agents or mtas should uh support it because yeah it's a hot discussion topic in the maing lists um third one being secur DLS connections as we could see from one of the previous slides uh D support was recently added to uh office and uh 065 uh 365 and uh I expect

that these implementations will start enforcing TLS in some cases like automatically they will detect that you have a valid certificate we're going to enforce it uh but uh one of the large gaps that haven't been yet addressed is the communication between mail us user agents and uh the MSA or MTA so when you have your web browser you can send a header from your web page that you want to keep all your uh Communications always encrypted uh there's no mechanism for this for male user user agents so uh in some cases like we we have seen in practice as well uh users click to the through the connection warning and send their credentials over uh uh untrustworthy

connection that has been intercepted and uh yeah this uh is quite dangerous uh another thing that we will likely see and work is ongoing is uh post Quantum asine uh we're going to see most likely either one of the two uh being implemented for smim uh large Casas are working on getting support uh in the relevant standards but um yeah this is as as mime does not have a lot of uh deployment just yet it's probably going to be faster than trying to get everyone using demarker or something and yeah another thing is that web browsers have recently added the post quantum uh key exchange uh support uh I think most of the major ones have

done so just yet and I would expect that at least some mail servers will do the same in some recent future when the libraries get the support because ml CM has been just recently standardized by nist so we'll likely see it more in the future and I think uh yeah now a short recap please stop using the length tag if you have used it in the past please rotate your keys if your rendor has shared your key with other customers force them to change it for you at least uh manage your setups properly make sure that you are not including Keys uh that have been long lost or whatever uh because I found an email from my own uh

mailbox sent by Microsoft uh 13 years ago its signature is still valid and uh interestingly enough that uh message was also uh sh signed using the Sha one algorithm it is estimated that the Sha one algorithm can be broken uh under 10,000 that is the PSI uh estimation from this year but in addition to sha one uh we also have like short uh Keys like 512 pit B the RSA keys that still exist in some cases those can be broken for less than 30 uh Euros so rotate those out as well otherwise even if you haven't sent any letters with them for a really long time it still allows forgeries uh please deploy SPF uh deim

and dmar because all of those in uh total uh do protect you from forgeries they protect your your company's good name they avoid a lot of customer support uh you have to offer if someone gets scammed uh it just avoids a lot of pain if you deploy it and do deploy it for your Park domains as well because we have seen that some of those uh are being abused uh it is kind of easier uh in some cases to detect those but still please do it for Park domains as well uh then make sure your mail server TLS configuration is good that at least you can receive email with uh using a TLS connection that can be verified uh even

if you do not want to enforce TLS for some reason I don't know what it might be please just make it do do so for others uh then if you can't deploy MTA SDS and maybe Dane if you have DNC if you have the tooling for Dane because uh DNS SEC and D tooling is not that great you don't have stuff like that in in the case of the SDS you just have to run your acma client just uh just like a search board or something so if you have a valid certificate MTA SS will just keep on working then makes it a bit more complex but still doable uh then you should stop using start TLS if your

documentation still recommends it maybe don't because there's actually no good reason for uh using start TLS over just TLS uh and then you should consider implementing Pim if you're like a large company that has uh large presents in like Estonia or something you might want to uh make it more visible to your customers uh that this letter is legitimate and sent by you not some kind of scammer that wanting uh five years and uh lastly uh if you have the option you can also deploy Asim just for signing this also has adds another uh check mark and uh yeah some customers maybe more in the future if people implement this m we might get more

clients supporting it in the future and uh yeah it might save us a bit of trouble as well thank you

so uh who wants to buy some speed yeah there we go I have to say this is a very very bold statement and a T-shirt and I I'm from cop very so so we had uh this list of these really prominent websites in Estonia that use this length tag have they been made aware of this and have they responded with plans yeah they have been informed through SE uh in this may uh and yeah the Improvement there has been some improvement but not enough and some people that stopped using the length tag itself did not rotate their keys so all of those old emails the T of thousands of emails that were sent are still uh

vulnerable to uh fores there's a question over there now we have a box actually I have two questions the first one is that what was the intentional purpose of this link tag in dkim the only thing I came up with that minimizing the body hash calculation time for long messages or uh yeah the initial intention was that mailing lists usually add a footer saying that this letter was sent through this mailing list uh to this person or something and uh in theory it could have allowed uh keeping the signature intact uh but in reality mailing lists uh change more uh than that uh just had a footer so uh it really had no practical beneficial effect and another thing that

uh people were thinking about were uh like uh security gateways but in those cases those gateways at the warning or whatever Banner to the top of the email breaking signature again so yeah no practical uh benefit okay and the second question was about mailing lists you didn't mention that them except in SRS and mention this is there any future in mailing lists or it's a think of the past well it kind of depends on your uh goal like there are are a lot of mailing lists still being used because uh what is the alternative uh using forums I guess but uh they serve an is and they seem quite alive but uh things like Demar and the SPF have made it quite

difficult but yeah with Arc and stuff like that things are uh improving for mailing lists as well and I just have to say standup comedians love mailing list because we can harass people who bought from us tickets on Phantom yeah yeah hey uh question here uh could you clarify what using start TLS please uh can you repeat the question Lo the middle of your question could you please clarify what the issue or vulnerability is with using start DLS so start DLS works by uh sending an explicit command to start the TLs session and starting that session uh first issue is that how do uh mailing servers know that you can actually start a TLS connection so that is advertised

in response to the extended hello command and if it's already encrypted your middleman can just remove the advertisement that DLS is supported now it also uh Falls open uh but another issue is that uh if you mix up encrypted and unencrypted Communications your message parer needs to handle both uh so mixing these two different kinds of operation uh is in practice really dangerous and has resulted in actual uh male user agents being vulnerable to various exploits because you have started your TLS connection but then the attacker can just send a plain text message uh the parser handles it just fine because it has to and uh yeah that is that is just bad and if we can get

rid of start TLS we can just simplify those code paths significantly