Okay, so this is the modern email deaf room and I think I'm talking about something rather
old and that is startillist.
So this talk is titled, why is it better without startillist, security analysis of startillist
in email context.
And this is based on research.
I've done some years back with Damian, so one of your lovely organizers here, Hanu Berg
and Sebastian Schinsel.
And my name is Fabian Easing.
So since I have the honor of starting off this whole, well, the whole deaf room, I want
to give you a quick overlook of at least the client side of the email ecosystem.
And this is a graphic I have designed from a dissertation and so bear with me that the
legend might not fit the context really.
But that's basically, well, it's hard to read in that resolution, but this is basically
a lot of the RFCs that go into the email ecosystem.
No worries, I'll cut that down a bit.
And I've basically identified three categories.
One is network protocols.
This is where we'll spend most of the time of this talk.
So this is SNTP, POP3, IMAP and nowadays JMAP, not included in the graphic yet, sorry for
that.
Formattings such as internet message format and MIME, so the multipurpose internet mail
extensions.
And lastly, end-to-end encryption like S-MIME at OpenPGP, which probably no one uses.
So in total, that makes up more than 150 RFCs.
Yes, some of them are obsolete, some of them are deprecated.
But if you really want to get the whole gist of just the client side of the email ecosystem,
you will probably have to read a lot of them.
And I've done that.
And they have done that.
So that's only one side of the mail, of course.
There's also implementations.
So over the course of my research, I've looked at more than 48 clients and more than 23 servers.
And this is by far not all of them.
So that's just the implementations I could get my hands on and not counting the ones
I found on the internet where I really can't tell if that is one of the 23 or isn't.
Okay.
Since I also have the honor of starting off this protocol session of the email deaf room,
I want to give you a quick, well, introduction to how an email gets from our sender Alice
to our receiver Bob.
So let's assume that both use some kind of mail user agent or what you would normally
call a mail client.
So for example, Mozilla's on the boat.
So both also need a so-called mail service provider.
That might be something commercial like mailbox.org or Gmail, you know, and well, that's basically
necessary to get one email from the sender to the receiver.
So Alice will first have to configure her MSPs, MSA or mail sending agent.
So what she has to do in our mail client is basically fill out some kind of dialogue like
this, put in a server, put in a port and choose an encryption mechanism.
Let's say for the sake of this talk that she chooses stateless or the auto configuration
told her to do stateless, which happens a lot of time.
So then she will be able to submit that over S&TP or submission if you want to be pedantic
to the MSA.
And Bob will have to do the same configuration with the mail delivery agent of his MSP to
be able to connect via POP3 and IMAP.
And then he will receive the mail, obviously.
So this is where we will stop for the sake of this talk.
So I'll be looking at the first and the last hope only.
However, I don't want to leave you hanging.
So what's happening in between is mail transfer agent to mail transfer agent communication,
which happens over S&TP.
And I'll report here be dragons there and whoever has looked into that knows what I mean
by that because that's generally from a security standpoint considered to be a pretty hazardous
field just to the reasons how DNS interacts with that and how DNS works or doesn't work,
they are and so on and so on.
So that's not what we will be looking at during this talk.
However, I think the first and the last hope are from a user standpoint, the most important
hopes simply because your credentials are submitted over that.
That means that you really, really want to have those connections encrypted by a TLS
if possible.
Or not only if possible, you want to do that.
Okay, let me give you a quick introduction to IMAP because that's what I'll be basing
my examples on and on start TLS.
So every IMAP connection begins with a client connecting to the server on a specific port
and receiving a greeting back.
This greeting consists of this asterisk and then a status code in this case, okay, and
usually a list of capabilities.
In this case, the server says, I'm able to speak IMAP for revision one and I'm able to
do the awesome login mechanism.
So far so good.
The client will then send tagged commands which consist of attack and a command as you might
have guessed and will usually receive some kind of data in response.
So that's called an un-tagged response.
And in this case, these are again the capabilities we've already seen in the greeting.
And finally, to signal that the server is done with processing this command, they will
send a tagged response with the same tag.
Okay, so far so easy.
Now how does that TLS work?
This basically is the same as you've seen before.
The client connects to some port, usually for IMAP it's 143 via plaintext, via plaintext
TCP connection.
And now the server sends the start TLS capabilities.
So that's the last capability here.
And usually removes all the locking capabilities because we don't want to have clients lock
in via plaintext.
Then they will negotiate start TLS.
So the client will say, hey, I really want to speak start TLS.
The server says, yes, okay, we can do that.
Then they'll do the TLS and shake and everything after that is encrypted.
Okay, although attacks happen here.
So we assume that the attacker is a meddler in the middle that can listen on the network
connections, that can modify packets, insert additional packets and so on.
But there will be no meddling with the TLS and shake, no trying to change any cipher
text and so on and so on.
So everything still happens in plaintext.
Okay.
At this point, you might be asking, so what is there even for an attacker to do?
Well, an attacker could, for example, change this or this or remove this, change this status
code, add something here or really do anything in between.
So there's actually a lot of room for stuff to do.
Of this, accumulated in USNIC security 2021 paper with the same title as this talk.
And as I've said, this is a paper from 2021.
So most of the bugs I'll be showing you today are hopefully fixed.
For most of them, we know that they are.
For some of them, we are not 100% sure.
But most of them are fixed by now.
So the questions we set out to ask were, first, are modern clients opportunistic?
So StatiLS has the reputation of being an opportunistic encryption protocol.
So basically, only if the client and the server can agree to do encryption, then they will
do encryption.
Otherwise, well, they will probably talk in plain text.
This should never be the case for client-to-server communication.
This is where this MTA to MTA communication falls into place.
That is usually opportunistic, hopefully not as much anymore as it was in the past.
But for clients to servers, you never want to have a plain text connection, actually.
So if there is data sent in plain text, so let's assume we are doing TLS, but we are
sending some data in plain text before that.
And we wanted to know if there's any sensitive data sent in plain text to the server or to
the client.
The third question was, so if there is some data sent in the plain text, is it retained
in the encrypted and authenticated context after the TLS handshake?
So does anything slip over from one context into the next one?
And finally, what happens in error cases?
Specifically, we looked at alert mechanisms like the IMAP's alert code, which you will
see in a moment.
All right.
To answer these questions, what we did was three-fold.
So we built the email analysis tool kit, the security tool kit.
I always forget what the acronym stands for.
I'm not sure.
It's East.
And it's on GitHub.
I'll put the link later.
So what we did was build almost full-fetched IMAP, SMTP, and POP3 server to automate tests
on virtual machines where we installed mail clients.
So basically, you can write a config file, define what do you want the server to answer
to specific messages.
And if you don't, it does what a normal server would do.
And otherwise, it will return whatever you told them to.
So the second one was, we wrote some scripts for IPv4 Internet scanning to scan for a specific
vulnerability on the Internet.
And finally, we built also some local test scripts with which you can test your own implementations
or your local installations.
All right.
So what were the key findings?
The first finding was that clients can be tricked into not using StarTales at all.
So they will leak credentials or emails.
So what you see on the right-hand side is a classic StarTales stripping attack.
So basically, you remove the StarTales capability from the greeting.
Then the client might still want to do StarTales.
So you just tell us, no, you can't do that.
All of that happens in plain text.
So why should the client not lock in?
This thankfully doesn't work in most of the clients nowadays.
So all of the StarTales stripping attacks, we found some of them, but usually they are
not a problem anymore.
However, we rediscovered a problem related to the pre-OS greeting.
So the pre-OS greeting is used whenever the server can authenticate the client over some
other channel.
For example, people apparently use IMAP over SSH.
And then you are already authenticated over SSH, so no need to re-authenticate to your
IMAP server.
So the client would receive this greeting from the server, which tells them, well, you
are already authenticated.
The client would then do StarTales.
Wait a second.
The IMAP-RFC states that the StarTales command is only valid in the not authenticated state.
So they really can't do that here anymore.
And most clients didn't.
So of course, they won't block in then, because why would they?
They are already authenticated.
However, many clients decided to upload sent and drafted emails after that, because they
are already authenticated, and their send folder is missing for some reason.
So let's just upload that in plain text.
So this worked in 15 out of 28 clients we tested.
Thankfully only one library we tested, so one client library, was meant to be opportunistic.
So opportunistic StarTales is really not the thing in clients anymore.
That's at least fortunate.
So the second key finding was that many clients process unauthenticated data that appears before
the TLS handshake.
So for example, we injected this alert message from IMAP, which then looks like this, for
example, in Microsoft Outlook.
This looks pretty real to me, if I look at it.
And it also helpfully highlights links for us.
So you can't do HTML in there or something, but you can still highlight links.
So I might be tempted to click on that if the link looks somewhat convincing as well.
So we found another case of that.
You can basically all of these untaxed response I've shown you before, only somewhat bound
to a specific command.
So you can basically inject them at any point before the TLS handshake.
And this results, for example, in this is, I think it's Sonabird, creating an attacker-controlled
folder in your mailbox.
And this stays even after the hijacked connection.
Also not too great.
So we were able to do this in at least 11 out of 28 clients.
So still a lot.
So what concerned us most was the last finding, that several servers were vulnerable to a
long-known bug.
So this bug was first detected by Vizavine M9's post-tix SMTP implementation in 2011.
So more than 10 years ago.
Should be fixed by now, right?
So this was first described for SMTP, but we have described it also for IMAP and POP3
and it's pretty straightforward that that should be the case.
This is also a problem there.
And basically what happens is the attacker injects a second command after the start TLS
command in the same TCP segment.
So basically this BNOUP shouldn't really be there.
So and what happens usually for servers is that they read the whole buffer.
So they read the whole socket into an application buffer, all data that is available, read both
commands, process the start TLS command, send an AOK to that, do the TLS handshake, and
that BNOUP remains in the application buffer to be handled after the TLS handshake.
And at this point it's interinspirant to the server that this wasn't sent over TLS and
this was basically sent by the attacker.
So they also answer after the TLS handshake.
So we were able to do that in eight out of 23 servers.
Remember this is a 10-year-old bug and over the course of the 10 years more than 16 of
the 23 servers were vulnerable at one point.
So basically this is widespread problem.
So we thought about that and thought well we can straightforwardly extend that to clients
as well because if we can inject a command why shouldn't we be able to inject a response.
So we did that and found 16 out of 28 clients basically vulnerable to the same bug simply
because it wasn't described before for clients.
So what's the impact of that?
We were able to do credential stealing in IMAP and SNTP, stealing and send and drafted
emails in both protocols.
We were able to tamper with the mailbox in both protocols that have mailboxes, do UIS
boofing in all three protocols, and we're even able to do HTTPS hosting under the IMAP
certificate of the server, which is pretty bad.
So what can we do about that?
Our first recommendation for users was to disable StarTLS in their clients and I think
that's still sensible.
So not disable it totally but switch to implicit TLS.
Please don't do plain text.
So do implicit TLS instead.
But we realize this might not be a workable solution for server developers and MSPs.
So if you really must use StarTLS you should isolate the plain text phase completely from
the TLS phase, from the encrypted phase, fix the buffering issues in the process hopefully
and as a protocol measure we should really streamline the negotiation and lock down what
is allowed before the TLS handshake.
So only accept the bare minimum of messages before the actual TLS handshake.
So as a final note, a quick thank you to all the developers of open source mail clients.
The response time to our bug reports was phenomenal, much, much better than the commercial
ones.
So if you want to test your own clients or your own servers, all our testing scripts
are available.
We're happy for any push, any pull requests, it's pull requests, not push requests.
This is the QR code I'll post it in the matrix chat after.
So in conclusion, StarTLS only extends the attack surface.
Not only do you want TLS but you don't really want StarTLS.
StarTLS issues are widespread among implementations and cross protocol attacks are possible for
example against HTTPS.
So in conclusion, TLS is better without StarTLS.
Thank you.
Is there any questions in the room or in the chat which somebody wants to relay?
Raise your hand and I can't with the microphone.
I see people are impressed.
Hi.
Alexi, when we were doing, I'm up for revision two.
I got some of your comments.
Did we fix all of these?
Can you reopen the PDF, please?
There's a slide on that.
I can do that.
Are we at the beginning or at the end?
So yeah, I'm up for revision two.
Fixed at least most of the stuff.
So pre-ass, there's a warning for that.
Clients must require TLS or clients that require TLS must close the connections.
So no more problems with pre-ass, hopefully.
Alert responses got a warning.
And I think this one is a specific comment on the buffering issues.
What's missing from My Point of View is a comment for the clients to do that as well.
So this client only mentioned servers, but the response injection is not handled in the
IMF RFC currently.
That's the only thing that's missing from My Point of View.
Okay.
Thank you.
Dave?
Is there a question?
This will be a spotty day for me.
So can you say something about the general security of email?
When I send an email to you, can I reasonably trust that it encrypts all the way?
That really depends on all the MTAs in between.
So I wouldn't make any general comment on that.
Maybe if you are using a somewhat securely configured mail server, and I'm using a somewhat
secure configured mail server that should work, but I wouldn't count on it for all the
servers on the Internet.
So basically from our scans, we know that many servers are not securely configured.
All right.
Not sure if you have time for one more question if there's one or otherwise we proceed looking
at the timekeeping.
Is there any final question?
So let's switch.
Thank you.
And thanks, Bobby, and again.