Our next talk comes from Turkey. It is with great pleasure to welcome and introduce you to Oskan
Mustafa Akkus and his talk, The Vulnerability that Gmail Overlooked and Enabled Threat Hunting.
Take it away, Oskan.
Hello, I wish happy days to everyone. I am Oskan Mustafa Akkus. Today I'm going to talk about
the threats that the SMTP protocol can pose and show you how large mail
providers such as Gmail overlooked and enabled threat hunting. It makes me sad not to be in
Vegas right now, but health is more important than anything, so please be careful and don't
go out without a mask. First of all, I want to talk about myself. I'm a vulnerable researcher
and penetration tester in Turkey. While studying sports science and technologies,
I decided to leave the university and step into the world of cybersecurity. My purpose is to
provide added value to the world of cybersecurity through the training I had given and the research
I had conducted. I published security vulnerabilities on international platforms
that I had discovered. I entries my exploit to CVE and EDP databases. You can also access my
previous works on my personal blog pentes.com.tr. I would like to mention presentation schedule.
First, we will focus on SMTP protocol structure and threats. We're going to analyze by sending
training emails inspired by SMTP, and then we're going to review and result and scheme
of the research. Finally, I'm going to share an explosive tool as a bonus with you.
I don't have the DEF CON 28 badge today. Because of that, I am using DEF CON 26 and 27 badges.
I miss it using them very much. So, let's start.
Let's look at what SMTP is. Also, let's take a look at the structure of this protocol and
examine the logic of operation. As everyone knows, SMTP is simple mail transfer protocol.
As mentioned in the name, it's very simple protocol. We know that the simple structure
can always pose a danger. So, new solutions and models contribute to the straightening of
the simple structure. Different solutions were used for many security problems in SMTP.
We're going to touch this issue again later. SMTP was published as IFC 788 by Postel in November
1981. This protocol structure was finalized as IFC 821, IFC 2821, and IFC 5321.
IFC 5321 is the last standard published in 2008. Today, there are famous structures that
high mail transfer agent is the use of the SMTP protocol such as Gmail, Postfix,
Microsoft Exchange Server, Yandex, Mail.ru, Yahoo, and so on. You can examine the history and
final version of the SMTP protocol in detail through the link below.
According to Internet Engineering Task Force, the simple structure of the SMTP protocol can
be shown as follows. Let's follow a path from the simple structure to complex structure.
Below, we can see the structure that is not separated into its components. So, SMTP clients
communicate via the internet. Let's continue the review by adding protocol components. If we move
to from general to detail, it will be more memorable. In the diagram below, you can see that we have
divided the SMTP client and SMTP server into two components such as mail transfer agent and
user agent. The user agent creates the envelope then puts the message in the envelope. So, it
prepares the message. The mail transfer agent transfers his prepared mail across the internet.
This is done in the same way on the parties receiving the mail and delivering the mail.
Up this time, the SMTP protocol was in a very simple state. Spring made trails with the simple
structure. Therefore, different structures are included to strengthen the SMTP protocol. For
example, extended SMTP has been released. Extended SMTP defines a framework for extending SMTP
service by defining a means whereby a server SMTP can inform a client SMTP as to the server
extension it supports. So, control has been added to DNS site which is used especially for email
transfer. Authentication to SMTP server, domain case identification mail, domain-based message
authentication, reporting and conformance, and standard policy framework are the controls provided
on the DNS site. While many standards have been published to strengthen the SMTP protocol,
the most important of this is the standard policy framework. This will be the point we will focus on
today. At this point, we will review the Internet Engineering Task Force's documents again. According
to Internet Engineering Task Force, IFC 7108 is version 1 for standard policy framework for
authorizing use of domains in email. You can get detailed information from the link below.
There's a sentence like this in the abstract description. This sentence is exactly like this.
Email on the internet can be forgotten in a number of ways. In particular, existing protocols place
no restriction on what a sending host can use as the mail from of a message or the domain given on
the SMTP hello, hello comments. This part is very important. Existing protocols place no restriction
on what a sending host can use as the mail from of a message or the domain. This means that the
SMTP protocol is a very primitive structure. It's ironic that the millions of the servers are not
using mail from control while using this protocol. Our main subject today is how famous mail transfer
agent services can pause a trade event thought they use SPF. In fact, today I was gonna just
share a situation related to Gmail, but it was March 3 when I applied for Package Hacking Village,
so I continued my research and perform a test on other famous email providers.
So today we will examine also other famous mail providers, not only the Gmail. These will be
Gmail, Yandex Mail, Mail.ru, Outlook, Hotmail, Yahoo, Zoho Mail, Hi.com, and HubSpot.
Because of that, it will be more correct to change the presentation title as
the vulnerability that famous email providers overlooked at enabling trade hunting.
Let's send emails that can pause trades and analyze the situation later. I worked on Exploit
to send these training emails. I'm so sorry to say that, but I'm not gonna share the details
of Exploit because it's so dangerous. However, I'm gonna show you with live examples. I'm gonna
use an SMTP server as a gateway by authentication with user information. This server will be an SMTP
server without open relay. In addition, this server must be a trusted server that has been
previously approved by famous email providers and has no problem with mail delivery. The server I
use in Exploit for this process will be my university's mail server. The servers of large
companies and universities are in constant communication with famous email providers,
so we can bypass most of the DNS-based controls. If you try to do this by creating a new server,
you're gonna definitely fail. There's also another detail in the Exploit I wrote about that,
but I'm not gonna share these details as I said before. We're gonna conduct internal and external
tests on famous mail providers. In internal tests, we will try to send arbitrary mail via
mail providers' own domain name, for example, gmail2gmail. In external tests, we will try to
send arbitrary mail using the domain name walloffship.com. Let's analyze these training
emails by sending them. I created a special account on all of the famous email providers.
We're gonna perform internal and external tests throughout these accounts. We're gonna do tests
on Gmail, Yamnix Mail, Mail.ru, Outlook, Yahoo Mail, Zoho Mail, Hai.com, and HubSpot.
My Gmail account was forwarded to HubSpot. It's also forwarded to Hai.com too.
Therefore, we're gonna also test Hai.com and HubSpot with email we sent to Gmail.
In internal tests, we will try to send arbitrary mail via mail provider's own
domain name. And then we're gonna analyze the results.
We're gonna send the mail from defconn.gmail.com to defconn.pishui.gmail.com first.
Let's start with Gmail. I'm gonna send it.
It will be passed. We need to wait a little.
And mail has been sent successfully. As you can see, the mail dropped on the inbox.
However, there's a big warning that this mail could not be verified that it came from
defconn.gmail.com. But when we look at Hai.com, there is no warning here.
This is a very dangerous situation. Similarly, when we check the HubSpot,
we see that the mail is successfully forwarded and does not contain any warning too.
I'm gonna explain the source of this vulnerability to you later.
Let's continue our test with Yandex Mail.
Now I'm gonna send email from defconn.yandex.com to defconn.pishui.yandex.com.
I'm passing information here.
Yeah, mail has been sent successfully. I will check the inbox.
And I reflect the page and check the inbox and spam box again.
But no email came. Yandex didn't allow us to construct its own domain name.
So let's continue the test with mail.ru. I'm gonna send email from defconn.mail.ru
to defconn.pishui.mail.ru. I'm passing information.
Mail has been sent successfully. I will check the inbox.
I'm gonna check back again to make sure.
No email came. Mail.ru didn't allow us to control its own domain name such as Yandex.
So let's continue the test with Hotmail. I'm gonna send email from defconn.hotmail.com
to defconn.pishui.hotmail.com. Mail has been sent successfully.
I'm checking the inbox. No email inbox, but as you can see it dropped into the spam box.
The mail is here. And let's continue the test with Yahoo Mail.
I'm gonna send email from defconn.yahoo.com to defconn.pishui.yahoo.com.
Mail has been sent successfully. I'm checking the boxes.
Oh, Trump came to his own mail.
And no mail came. Yandex didn't allow us to control its own domain name too.
Let's continue the test with Zoho Mail. I'm gonna send email from defconn.zohomail.com
to defconn.pishui.zohomail.com. Mail has been sent successfully.
Let's check the page by reflashing. I'm checking the boxes.
No mail came. Zoho didn't allow us to control its own domain name too.
So internal tests are over. We can pass to external tests.
Time to external tests. I'm gonna use the email address mink
at walloffship.com for external testing. We're gonna send email from mink at
walloffship.com to other email addresses. Let's start with Gmail.
I'm passing. Mail has been sent successfully.
At the same time, the mail dropped into the inbox already.
As you can see, we cannot see the warning here as internal tests.
When you browse the first mail, you can see the difference,
but there is a small detail. There is a question mark in the profile photo.
When we move the cursor to this point, we notice that there is a warning again here.
It says your mail could not verify that walloffship.com actually sent this message.
But I don't know which user cares about this. I'm gonna show an example later on this situation.
Let's check out hey.com and HubSpot now. As you can see, mail has been forwarded
without any warning such as an internal test. The situation looks the same for HubSpot too.
There is no warning and mail is cleanly forwarded.
I also want to show you what's happening in the Gmail application.
I'm gonna show you an older version. There is no warning even in the profile
photo in the mobile application. However, until two months ago,
it was affected by this weakness in the last version.
I didn't report them, but they fixed the vulnerability. I don't know how they learned.
Maybe my mails may be under review. I don't know.
But still, I want you to know that the old versions are still vulnerable.
Let's continue tasks with Yandex Mail. I'm gonna send email from
mink at walloffship.com to defcomph3 at yandex.com.
I will pass the information. Mail has been sent successfully.
I will check inbox. As you can see, mail dropped directly into the inbox.
Also, there is no warning in the mail content. It's a very dangerous situation.
I'm not Mink, but it doesn't matter for Yandex.
Therefore, we can say that Yandex is affected by this situation.
I'm taking note of this and let's continue tasks with mail.ru.
I'm gonna send email from mink at walloffship.com to defcomph3 at mail.ru.
Mail has been sent successfully. As you can see, the mail has arrived quickly.
Just like Yandex, mail.ru didn't check if I was Mink or not.
Therefore, we can say that Yandex is affected by this situation too.
Let's continue tasks with Hotmail. Now is I'm gonna send email from
mink at walloffship.com to defcomph3 at hotmail.com.
Mail has been sent successfully. Now I will check.
And no mail inbox, but as you can see, it dropped into the spam box.
Hotmail sent this message to the spam box because it couldn't verify its owner.
So I am taking note of this. Let's continue tasks with Yahoo mail.
I'm gonna send email from mink at walloffship.com to defcomph3 at yahoo.
com. Mail has been sent successfully.
I'm checking the boxes. I'll tramp again, I think tramp is after me.
I will check boxes a few times to be sure.
No mail has been received. Yahoo is very strict about this.
I take note of this and pass the final external test of Zaha mail.
I'm gonna send email from mink at walloffship.com to defcomph3 at zahomail.com.
Mail has been sent successfully. I'm checking the boxes.
And no mail has been received, so Zaha mail is very strict about this, such as Yahoo.
This was our last test. It's time to analyze the information we collect.
As an example of my research, I caught a very interesting example.
I want to present this to you. My friend was accepted by defcom Red Team Village.
This news came to him from omar at redteamvillage.io.
When I review this email, there's a warning in the Gmail proper photo area, just like our external
test. My friend did not pay attention to this situation and answered this email.
Fortunately, the mail really came from Omar, but this could be a fake mail.
Now I'm gonna send an email from omar at redteamvillage.io to my friend gmail artist.
We're gonna also carry out internal and external testing and
look at the response of the email application on the Apple Mac device to this vulnerability.
Let's send the mails. I'm gonna send these test mails from my second screen.
As you can see, the mail from defcom at gmail.com also cancels a warning in the Gmail web application.
However, in the email application of the Mac operating system, this mail does not
cancels any warnings. This is a very interesting finding, too.
In addition, the mail I sent from Omar successfully reached the application
allowed me to pass whether I was Omar or not. Now, time to examine where this vulnerability is
caused. Now I'm gonna show where the vulnerability originated. As I have shown before,
we're gonna examine why third-party applications cannot detect this little warning in the profile
photo area and why are they receiving this training mail cleanly from Gmail.
Let's look at what's happening again. Hair.com does not have any warning.
Also, HubSpot does not have any warning, too, as you can see.
Mail that is perceived as dangerous in Gmail looks completely clean on these platforms.
To show that, I'm gonna use Python library writing for the Gmail API.
With this library, we're gonna check the email contents by making a request to the Gmail API.
First, we need to learn the ID value of the message we want to link.
And I think that should be it. I need to put this ID value into the library properly.
We also need to use GET instead of LIST. It is now ready to make request again.
As you can see, all the details of the mail are here. After a little examination,
we realized that the warning in the Gmail web application is not among the information
received with the Gmail API. Therefore, we have proved that third-party applications such as
Hair.com, HubSpot, and Apple email applications cannot detect this warning because
they use the Gmail API. There are dozens of applications using the Gmail API,
so this vulnerability caused by Gmail affects them all. In this case, it leaves millions of
people directly in danger. These applications which can connect with Gmail need to make a
new update considering this situation. Once and for all, let's examine the result of our internal
and external test again. Let's take a brief look at the result of our test.
I'm going to summarize this part quickly. The meaning of the signs are here. In internal tests,
training mails drops into the inbox with warning in Gmail and doesn't drop into any box in Yandex
and doesn't drop into any box in Mail.ru and drops into the spam box in Outlook and doesn't drop
into any box in Yahoo and doesn't drop into any box in Zahoomail too. In external tests,
the training mails drops into the inbox without warning in Gmail and drops into inbox without
warning in Yandex and drops into the inbox without warning in Mail.ru and drops into the spam box in
Outlook and doesn't drop into any box in Yahoo and doesn't drop into any box in Zahoomail too.
Unfortunately, third-party applications using APIs of famous mail providers cannot reflect
warnings. Initially, the incoming email is forwarded directly without an error message.
So, Hide.com forwarded training mails and mails dropped into the inbox without warning. Also,
HubSpot forwarded training mails and mails dropped into the inbox without any warning too.
This was the test result with it. I'm sharing an exclusive tool with you at the last stage of my
presentation. Its name is DraftChat. DraftChat allows persons to chat throughout mail providers.
You can access the GOD chat module, which is the first module and uses the Gmail API.
DraftChat allows persons to chat throughout a single Gmail account in the Gmail that does not
record drafts. It encrypts the sent message first with DES and then with the AES algorithm and writes
them to the created draft. The message of person I've written in encrypted form on the same draft.
Message can only be read with the correct case to be determined. In this way, a completely hidden
chatroom is created with a single Gmail account. Therefore, DraftChat makes person-hundred private
communication opportunity by turning a non-URL mail server into a chat server. You need to set
up a common Gmail account to chat with your partner. Remember, you will only perform this
operation once. You will not have to do this configuration every time you chat. Let's do the
installation pace in a practical way. First step is turn on the Gmail API. First of all, we need to
allow for quick start from our Gmail account, because we are using fighting quick start. Click on
enable the Gmail API button. In this section, you should choose the desktop. In zone link dialog,
click download client configuration and save the file credentials.json to your DraftChat directory.
After running DraftChat, it will first ask you for your nickname. Once you have determined
your nickname, you must determine whether you want to be a server or a client. Client-server
relationship is very simple. If you want to be a server, the DES and AES keys that you determine
will be used. If you choose to be a client, you have to get keys for these algorithms from your
server partner. Let's say you choose the server option. After the retirement and 8-digit DES key,
DraftChat generates a 16-digit random AES key for you and a new draft is created for the chat rooms
that your client partner is expected. So you need to pass this case over to your partner.
Let's take a look at the client option. In this case, I have taken an entrant from the server
partner. If the keys are wrong, there is no server rating for the client, the program will give an
error. The taken keys were entered and the information was verified. So you can communicate
with your partner in peace of mind. When the draft box of our Gmail account is checked,
you can see that a new draft has been created here. All messages are written here and the draft
is continuously encrypted with algorithms. We can test this by writing a new message.
It's for grids. The fact that you are offered a private chat room does not mean that the
communication you provide while using this tool may be illegal. Remember that all the responsibility
belongs to you. You can download DraftChat from GitHub. It also opened the development. You can
contribute to this tool if you wish. Yes guys, now it's over. Thank you so much for listening to me.
You can contact me from my social media accounts and you can ask your question whenever you want.
I was honored to be here at DEF CON 28 Package Hacking Village. I hope to present my research
at that best hacking conference in the world next year again. I wish healthy days to everyone.
Best regards. Goodbye.