So today I'm going to explain to you how you can hijack a web application before it's even
installed and use certificate transparency for that. So to get started, so you all know that
we're using much more HTTPS these days, so there's a lot of effort to move the web to encrypted
connections, like Google gives you a higher search ranking if your site is using HTTPS,
and there have been initiatives like Let's Encrypt to make it easier.
So yeah, so HTTPS is a very important piece of modern web security.
And part of that is certificate authorities. So if you want to run a web page with HTTPS,
you need a certificate and that needs to be signed by one of these certificate authorities.
And here are some of the bigger ones, like Komodo, Symantec, and Let's Encrypt,
which is like a new and free one. And one question that comes up quite often is,
do we trust certificate authorities? And for many people, the answer to that question is just,
no, we cannot trust them. Because like there have been a lot of incidents in the past where
certificate authorities have issued certificates for domains where they haven't been asked for,
or even for rogue purposes for attacking people. So many people don't trust the system very much.
And something I hear very often is that people say, yeah, this whole system is broken. We need
to get rid of it. We need to completely replace that with something else. That's something I hear
very often, especially in the IT security community. The problem, however, with that is
in reality, I think nobody really has a plan with what to replace certificate authorities,
or at least not any plan that is realistically feasible. And so what has been happening a lot
in the past couple of years that people have thought, how can we improve this system? How
can we make the existing system more secure? One thing that has happened is the so-called
baseline requirements. So that's just a document that is writing down the rules under which these
certificate authorities operate. So how they should issue certificates, how they should check
that a domain really belongs to the domain owner. And that's already improving a lot,
because if something strange is going on and the certificate authority is doing things that it
probably shouldn't do, then there's probably something in the baseline requirements where
you can say, hey, here's a rule that's not allowed. Then there's a technology called
HTTP public key pinning, which is a very strong protection, but it's also kind of dangerous,
because you could pin your site to a key and then lose the key. So this is a very strong
technology, but you probably shouldn't use it unless you know exactly what you're doing.
One other thing is called CAA, certificate authority authorization. What's happening
there is that you can define a DNS record which is saying, I only want certificates from this
specific certificate authority and not from any other. And then there's this thing called
certificate transparency, which will be the main topic of my talk. And the idea here is that we
have public logs of certificates. So all the certificates, we put them in a log that is also
verifiable in some cryptographic sense. So there's more transparency in that system so that
people can watch what's going on. So I'm not going to talk about the details of how that works. So
there's a lot of fancy crypto. There are a lot of acronyms like signed certificate timestamps,
etc. The basic idea is all of that is to prevent cheating in that system. So the idea is to make
it really hard for any actor in the system, whether it's a certificate authority or log operator,
to make something appear like it isn't really. So these logs have some cryptographic integrity
and it is very hard to log something and then remove it again from the log without that being
noted. So right now this is not fully implemented, but starting next year, at least according to the
current plan, this has been changed. But according to the current plan, next year in April, there
will be a requirement for all new certificates that they need to be submitted to at least two
of these public logs. But in practice today, a lot of certificates are already logged and there
are a number of reasons for that. So there are some certificate authorities that already submit
their certificates to logs. One of them is Symantec and they do it because Google said
they have to do it because there were a lot of issues with Symantec in the past. Let's Encrypt
is doing it voluntarily because they say they want to support this. They think this is a good
system. Also Cloudflare is doing it, so if you register a Cloudflare site, you automatically get
HTTPS and they submit the certificates to logs. And also the Google search engine crawler, so
if the crawler from the Google search engine surfs to your site and you have HTTPS,
then they will download the certificate and submit it to their logs.
So in practice, that means already today, a lot of certificates are in these logs and get
submitted pretty quickly to these logs. So you can think of certificate transparency a bit like
a CA watchdog. So everyone can look into these logs and see if there's anything that looks in
any way suspicious. So the most obvious thing is to look into these logs if there are certificates
for your own domains that you haven't ordered yourself. So if there's a certificate for my
domain and I don't know about it, then something is wrong. That's obvious. But there's also things
like if you look at this certificate, what's a bit suspicious here is that it's only valid for
one day and it's for Google com. That was an internal test at Symantec. Apparently they have
submitted the certificate from the internal test to the public log. So Google found out about it.
So it's a certificate for Google com, but it's not from Google. So that started the whole
Symantec controversy. This is also interesting. So does anyone see what's wrong here?
So if you look at the location, it says it's in Rotterdam in California in the Netherlands.
So I don't know about your geography skills, but California is, as far as I know,
not part of the Netherlands. Maybe there are some similarities, but yeah.
This one is also interesting. So here you can see in one of the lower lines, there's a domain
name with two dots in it. So it says dot dot this, and that's not a valid host name. So we can
be sure that there's no way anyone has really checked that this host name belongs to anyone
because it's an invalid host name. It cannot belong to anyone. So here you can see that this
system really works. People are looking at these logs and are seeing, okay, here's something
strange, here's something fishy, and we should report that, and yeah. And hopefully then the CA
will not do it again in the future. If you want to check this out a bit, there's a search engine
for certificates and certificate transparency under your LCRTSH. That's very nice. That's
operated by Komodo. So for example, the very easiest thing you could do right now is search
if there are certificates for your domain that you don't know. But on the other hand,
certificate transparency is also a kind of data source. Because we have all these certificates,
okay, for example, they contain, as we have seen sometimes, the location and also they contain
host names. So for example, if you operate a search engine, this could be interesting because
you could know, okay, here are all these hosts that have web pages, so maybe I look at them.
So in a certain sense, certificate transparency gives you a kind of feed for new host names.
So if you're permanently observing these logs as they are public, like there's an API,
you can just simply request the new certificates from them, and then you can look into these
certificates and see host names. And when someone creates a new web host with HTTPS and gets a
certificate, then it will end up in logs, so you kind of have a feed of new web host names.
So now I want to switch the topic a bit to something which may appear like something
completely unrelated at first, and that's web applications. And when I talk about web
applications here, I mean things like self-hosted web applications. So things like WordPress,
Joomla, or things like Nextcloud. These are usually written in PHP, usually use MySQL,
you probably all know one of these like typical content management systems and similar things.
When you install one of those, what usually happens, so you upload the files from the
software to some web hosting company or on your own server, and then usually you just call the
web page and get an installer and click through a few things. It asks you for your database
credentials, then it asks you to create an initial administration account, and then you have
installed your application. What's notable is there's no authentication whatsoever. So these
installers have no protection, so everyone who, like if someone else calls this installer, he can
install it just as well. And this has been known for a while, like people have been using Google
to search for uninstalled WordPresses that have been abandoned, like maybe someone has
uploaded them and then a problem happened and they just forgot about this installation.
And if you find them with Google, then you can take them over.
But the new idea here is there's a small time window between when a webmaster uploads this
application and when he finishes the installation. And if we can hit that time window, we have an
attack, because then we can do the installation and then we are in control of this application.
And you might see where this is getting at. You may remember from earlier, we have this
feed of new host names. So if we combine these things, we have our attack. So we can monitor
the certificate transparency logs all the time, probably with some kind of con job,
automated, and extract all the host names. And then we check these hosts, like we do a
curl or a wget on them, and compare what they are currently serving as a web page
to common application installers from WordPress, from Joomla, from whatever.
So, and if you find one of them, we install this application ourselves.
And if we're a real attacker, we would probably do this automated. Of course, it's faster.
Now then, when we have done this installation, we can upload a plugin, because all these
applications usually have some kind of extension mechanism where you can upload a plugin, and
basically that gives you code execution. And ideally, we upload something that gives us
further code execution, so we can just then execute arbitrary code.
And what we do then is that we revert the installation, because how these installs work
is usually just when they finish, they write down a config file, and if we delete that config file,
then the installation is undone. So one thing we need for the whole thing are database credentials,
but that's not a problem, because you can just define an external MySQL host,
and there's, for example, a service called freemysqlhosting.net,
which offers free MySQL hosting, which is very convenient for what we're trying to do.
Yeah, so we have a little demo.
So what I'm doing here, this is the search engine I mentioned earlier,
and what I'm now doing is I put in a percent, which is a wildcard character,
and then I put in .tlsfun.de. That is one of my own domains.
And I'll make this a bit bigger. You see, the very latest entry here is for blog.tlsfun.de.
And let's just copy that URL and see what we can find there.
Oh, this is a WordPress installation. That is nice. So we click on continue,
and click another button. Okay, now we need these database credentials.
And as I'm prepared for this, I already have database credentials here,
as I said, from free MySQL hosting.
And password, and this host. Okay, run the install. So now I need a site title,
I just use test, username admin, want some password for me,
and an email. There, I just use something like trash mail.
And installation. Now it takes a bit...
Okay, so it says WordPress has been installed. Thank you and enjoy.
Login. So now I'm logging in with the admin account I just created with the password I just
typed in. Okay, and now I go in plugins, and click on add new. And so here I can just install
plugins from WordPress itself, but I can also click on upload plugin. So I can upload my own
plugin, which I have prepared before, which is called hijack, and we'll install it.
Okay, so now in this plugin, I have a file called shell.php, and it doesn't show me anything,
because it wants a secret. Secret is DEF CON 2017. It's not very exciting, but okay.
Okay, and this is a very simple PHP shell. So we can make ls, and we can also...
Okay, now the screen is cut off. That's not very good. But I can show you, for example,
if I type in uname, then I get output of uname. So I basically have a shell now.
And the interesting thing is I also here have a button which says remove installation traces.
I'll just try to let you see that. Yeah, that's better.
And now if I go on this again,
then you see the installer's back. And that is important, because the person who is the owner
of this WordPress, which in this case is me, but in the real case is someone else, will never notice
what happened. So I have a backdoor now. I can execute arbitrary code on that server, but the
owner of that WordPress installation will never notice it. At least that's what we hope. Yeah.
So one challenge here that we have is that the certificates are not immediately public. There's
a time lag, which so it is a maximum two hours, but I have kind of measured it, and it's usually
about 30 minutes. So from certificate issuance until the certificate ends up in the lock.
But it doesn't really matter, because there are still like enough people who will just create
that host and then upload that WordPress and then go for a coffee and finish the installation later.
So we'll just hit enough vulnerable hosts in that time frame. And this could also be further
optimized, like you could say, I'm not only checking a site once, but when I see a new host
in the certificate transparency locks, I just check it every five minutes again and again for
maybe a couple of hours. So I ran a test script where I was searching for these installs
this certificate transparency locks over three months, and I could have taken over 5,000
WordPress installations in that time. So that's quite a nice spot net if you have 5,000 ways to
execute PHP code, use that to send spam or host phishing sites or whatever. Also around 500
Joomla installations, 120 next cloud and 70 on cloud. The others were all quite low, so the
others I would say probably doesn't deserve the effort. One thing is Drupal doesn't show up
because their installer page is so slow that the time out of my script hit. But yeah, that's just
kind of a technicality. So how can you protect against this? So in very general, I think these
installers need to be authenticated. I think it's just not a good design to say I upload an
installer and then it's just without any protection out there in the internet and we just hope
nobody finds it. The challenge is, of course, the developers of these applications, they want to
make the installation as easy as possible. And if you add any kind of authentication, that
creates extra effort. So I can kind of understand that they are reluctant, but still this somehow
needs to be fixed. So one thing you could imagine is that the installation process creates a secret
token, writes that into a file, and then the user has to download that file and paste that token
into a web form and only then he can install the application. That's one option, but of course
there are other options as well. So I reported this to a couple of vendors, primarily the big
content management systems because they are the most interesting here. So from Drupal,
Typo3, and OnCloud, I got no reaction at all. They just ignored my messages. Then from WordPress,
NextCloud, and Serendipity, there came some answers like we would like to discuss this with
other vendors and can we have a cross-vendor discussion. And I said, okay, I'll set up a
mailing list. But then there was not a whole lot of discussion. This is interesting. MediaWiki
is not vulnerable to it and was not even before I did this research. And the reason is their
installer works a bit different. So when you finish the installer, they don't just write the
config file, but they provide the config file for download. And you have to download it and
then upload it again to your web host. Otherwise, the installation doesn't get finished.
Although, MediaWiki allows you to use SQLite. And SQLite is file-based. So the installer still
kind of allows you to create a file on the server. But you don't have a whole lot of control over it.
I don't think this can be exploited, but it's a nice challenge. So if anyone of you
has an idea how to exploit that, I would be very interested to hear about that.
And then Joomla. Joomla was the only content management system that implemented a fix
after I reported it to them. They released it a couple of days ago. And what they're doing
is that it was basically my idea. The problem is I don't... I later decided that I don't like
the idea anymore. So what they're doing is they're whitelisting localhost as a MySQL server.
So if you have a local database server, the installation is just like it was before.
And if you have an external MySQL server, then they have an extra authentication step.
And the extra authentication step is that it has created a directory with a random file name,
and you're supposed to remove that directory, and then you can continue the installation.
So why don't I like it? So the problem here is if you have a large web hosting company that may
have thousands of customers on a single server, then it may just be that the attacker already
has credentials for that server. Like he can just register a couple of accounts at major
web hosting companies. Or you could even think one step further. The attacker is, of course,
attacking multiple applications at once, and WordPress is still vulnerable. So chances are
high he may have already hijacked one WordPress on that server when he finds that Joomla, and then
he can use the database credentials from that WordPress to hijack that Joomla. So I don't think
it's an ideal fix, but at least I have to give Joomla credit that they were the only ones that
did a fix at all. Like the others just didn't do anything. So what can you do as a user? If you
think now, okay, that's a problem. I don't want my WordPress to get hijacked before I even use it.
How can I protect myself? You could say, okay. As I said, these logs are not updated instantly,
so you have like 30 minutes, but it's kind of a bit risky because like there's no guarantee how
fast these logs are. And it could just be that next month Google decides they make a super fast
log because they have optimized their software and it's running much faster and then this doesn't
work anymore. So I don't think it's a very good solution, but yeah, you can think about that.
Then there's the thing called certificate reduction. So with this certificate transparency,
some certificate authorities were worried that, oh, that means all these host names are now public
and our customers might not like it. Particularly Symantec now already offers that. So there is a
part of certificate transparency where you can have redacted domain labels. So you could say
this certificate in the log is for redactedlabel.something.com.
But I don't think that's very practical either. So for one, as soon as the Google crawler sees
your real certificate, you're still again in the log. And the other thing is not all certificate
authorities offer this. And this has been quite controversial. So I'm not entirely sure if it's
going to stick around. And particularly if you had some web host that automatically issues
certificates for you, they are likely not going to use this. So it's also not a very good solution.
You can use a htaccess file to just password protect your installation.
That works. A problem is that some of these applications use htaccess themselves to configure
things. And you need to make sure that that doesn't interfere. For example, if you finish
a WordPress installation, it creates an htaccess file. And what you can however do is that you put
your password protection htaccess file in the upper directory. Because like Apache server
goes recursively through all the directories to scan for htaccess files. That doesn't work at all
web hosting environments because sometimes you only have write access in your web root.
But if you have write access in the upper directory, then you can do that. And that's
kind of the best you can do right now as long as these applications don't protect you.
So, yeah. Defending as a user is hard here. And we really need fixes from vendors here.
Then I was wondering, do attackers already use this? Does anyone know about this attack? Has
anyone had the same idea? And do they already exploit it? So, I sent a couple of posts with
just random subdomains from my domains and checked if anyone would access them. And okay,
my own test script would access them. That's obvious. And I also saw this in the log file
which says Netcraft survey agent. So, Netcraft is a company. I think they mainly do statistics
around the web. So, I think this is non-malicious. And it's also a good example that this data,
of course, it can be used for attacks, but it can also be used for legitimate proposals like
doing statistics, looking for new websites. That, I think, is legitimate use of that data.
So, I think nobody is exploiting this yet, but that may change. Yeah. So,
major takeaway, I think, is unauthenticated installs are a security risk. And I really think
these web applications need to do something about that and should fix this.
Then one thing, and I think that message many people haven't gotten yet, there are no more
secret host names, at least if you use HTTPS. So, if you ever had the idea in my company I could
have internal secret something something dot company name dot com and there's an internal
backend interface that nobody ever will find, forget about that. That has been a bad idea in
the past anyway, because host names are not encrypted, even if you use HTTPS, the host name
is always visible on the traffic, both through DNS and through server name indication. But now
it's a really broken assumption. So, if you have HTTPS for your web pages, you must assume that
the host names are public. And it's also interesting if you're maybe a pen tester or
looking at a bug bounty program, this is a good way to search for host names from companies.
And, yeah, final takeaway, certificate transparency is a valuable data source,
both for attackers and defenders. And I'd like to say something that I find important. So,
when I submitted this talk, I feared a bit that people might use this as an argument against
certificate transparency. And therefore I want to make very clear that I don't think it is. I think
certificate transparency is an amazing system. It's probably the best security improvement the
TLS ecosystem has seen in a while. And I think the problem really lies elsewhere. Certificate
transparency is just kind of amplifying the problem of unauthenticated installers here. So, yeah.
Yeah, I think it was pretty fast, so we should have time for some questions. Thank you.