start	end	text
0	5700	So today I'm going to explain to you how you can hijack a web application before it's even
5700	13140	installed and use certificate transparency for that. So to get started, so you all know that
13140	19600	we're using much more HTTPS these days, so there's a lot of effort to move the web to encrypted
19600	26000	connections, like Google gives you a higher search ranking if your site is using HTTPS,
26000	29220	and there have been initiatives like Let's Encrypt to make it easier.
29820	34880	So yeah, so HTTPS is a very important piece of modern web security.
36480	42520	And part of that is certificate authorities. So if you want to run a web page with HTTPS,
42520	47160	you need a certificate and that needs to be signed by one of these certificate authorities.
47480	51580	And here are some of the bigger ones, like Komodo, Symantec, and Let's Encrypt,
51580	59200	which is like a new and free one. And one question that comes up quite often is,
59200	64560	do we trust certificate authorities? And for many people, the answer to that question is just,
64560	69600	no, we cannot trust them. Because like there have been a lot of incidents in the past where
69600	74820	certificate authorities have issued certificates for domains where they haven't been asked for,
74820	83340	or even for rogue purposes for attacking people. So many people don't trust the system very much.
84800	91260	And something I hear very often is that people say, yeah, this whole system is broken. We need
91260	97280	to get rid of it. We need to completely replace that with something else. That's something I hear
97280	103640	very often, especially in the IT security community. The problem, however, with that is
103640	108840	in reality, I think nobody really has a plan with what to replace certificate authorities,
108840	116820	or at least not any plan that is realistically feasible. And so what has been happening a lot
116820	120940	in the past couple of years that people have thought, how can we improve this system? How
120940	126840	can we make the existing system more secure? One thing that has happened is the so-called
126840	133080	baseline requirements. So that's just a document that is writing down the rules under which these
133080	139580	certificate authorities operate. So how they should issue certificates, how they should check
140200	145060	that a domain really belongs to the domain owner. And that's already improving a lot,
145060	150420	because if something strange is going on and the certificate authority is doing things that it
150420	154880	probably shouldn't do, then there's probably something in the baseline requirements where
154880	161940	you can say, hey, here's a rule that's not allowed. Then there's a technology called
161940	167580	HTTP public key pinning, which is a very strong protection, but it's also kind of dangerous,
167580	175920	because you could pin your site to a key and then lose the key. So this is a very strong
175920	182080	technology, but you probably shouldn't use it unless you know exactly what you're doing.
183100	189700	One other thing is called CAA, certificate authority authorization. What's happening
189700	195400	there is that you can define a DNS record which is saying, I only want certificates from this
195400	202500	specific certificate authority and not from any other. And then there's this thing called
202500	211700	certificate transparency, which will be the main topic of my talk. And the idea here is that we
211700	218720	have public logs of certificates. So all the certificates, we put them in a log that is also
218720	225340	verifiable in some cryptographic sense. So there's more transparency in that system so that
225340	233880	people can watch what's going on. So I'm not going to talk about the details of how that works. So
233880	242660	there's a lot of fancy crypto. There are a lot of acronyms like signed certificate timestamps,
243080	252380	etc. The basic idea is all of that is to prevent cheating in that system. So the idea is to make
252380	260420	it really hard for any actor in the system, whether it's a certificate authority or log operator,
260420	268640	to make something appear like it isn't really. So these logs have some cryptographic integrity
268640	274760	and it is very hard to log something and then remove it again from the log without that being
274760	287240	noted. So right now this is not fully implemented, but starting next year, at least according to the
287240	292860	current plan, this has been changed. But according to the current plan, next year in April, there
292860	298040	will be a requirement for all new certificates that they need to be submitted to at least two
298040	307500	of these public logs. But in practice today, a lot of certificates are already logged and there
307500	313260	are a number of reasons for that. So there are some certificate authorities that already submit
313260	318240	their certificates to logs. One of them is Symantec and they do it because Google said
318240	324020	they have to do it because there were a lot of issues with Symantec in the past. Let's Encrypt
324020	328380	is doing it voluntarily because they say they want to support this. They think this is a good
328380	334600	system. Also Cloudflare is doing it, so if you register a Cloudflare site, you automatically get
334600	340420	HTTPS and they submit the certificates to logs. And also the Google search engine crawler, so
340420	345780	if the crawler from the Google search engine surfs to your site and you have HTTPS,
345780	349080	then they will download the certificate and submit it to their logs.
349800	358120	So in practice, that means already today, a lot of certificates are in these logs and get
358120	365620	submitted pretty quickly to these logs. So you can think of certificate transparency a bit like
365780	371860	a CA watchdog. So everyone can look into these logs and see if there's anything that looks in
371860	377720	any way suspicious. So the most obvious thing is to look into these logs if there are certificates
377720	384260	for your own domains that you haven't ordered yourself. So if there's a certificate for my
384260	390180	domain and I don't know about it, then something is wrong. That's obvious. But there's also things
390180	396200	like if you look at this certificate, what's a bit suspicious here is that it's only valid for
396200	405140	one day and it's for Google com. That was an internal test at Symantec. Apparently they have
405140	410780	submitted the certificate from the internal test to the public log. So Google found out about it.
410780	417000	So it's a certificate for Google com, but it's not from Google. So that started the whole
417000	428420	Symantec controversy. This is also interesting. So does anyone see what's wrong here?
428420	437610	So if you look at the location, it says it's in Rotterdam in California in the Netherlands.
439010	445650	So I don't know about your geography skills, but California is, as far as I know,
445650	452790	not part of the Netherlands. Maybe there are some similarities, but yeah.
454010	459110	This one is also interesting. So here you can see in one of the lower lines, there's a domain
459110	466910	name with two dots in it. So it says dot dot this, and that's not a valid host name. So we can
466910	473250	be sure that there's no way anyone has really checked that this host name belongs to anyone
473250	482970	because it's an invalid host name. It cannot belong to anyone. So here you can see that this
482970	487730	system really works. People are looking at these logs and are seeing, okay, here's something
487730	494830	strange, here's something fishy, and we should report that, and yeah. And hopefully then the CA
494830	502410	will not do it again in the future. If you want to check this out a bit, there's a search engine
502410	508910	for certificates and certificate transparency under your LCRTSH. That's very nice. That's
508910	515370	operated by Komodo. So for example, the very easiest thing you could do right now is search
515370	522230	if there are certificates for your domain that you don't know. But on the other hand,
522230	529010	certificate transparency is also a kind of data source. Because we have all these certificates,
529010	533370	okay, for example, they contain, as we have seen sometimes, the location and also they contain
533370	539170	host names. So for example, if you operate a search engine, this could be interesting because
539170	544830	you could know, okay, here are all these hosts that have web pages, so maybe I look at them.
547810	554890	So in a certain sense, certificate transparency gives you a kind of feed for new host names.
554990	560430	So if you're permanently observing these logs as they are public, like there's an API,
560430	565550	you can just simply request the new certificates from them, and then you can look into these
565550	571650	certificates and see host names. And when someone creates a new web host with HTTPS and gets a
571650	577010	certificate, then it will end up in logs, so you kind of have a feed of new web host names.
578530	584430	So now I want to switch the topic a bit to something which may appear like something
584430	590550	completely unrelated at first, and that's web applications. And when I talk about web
590550	596390	applications here, I mean things like self-hosted web applications. So things like WordPress,
596390	603870	Joomla, or things like Nextcloud. These are usually written in PHP, usually use MySQL,
603870	610110	you probably all know one of these like typical content management systems and similar things.
610830	618510	When you install one of those, what usually happens, so you upload the files from the
618510	626230	software to some web hosting company or on your own server, and then usually you just call the
626230	631990	web page and get an installer and click through a few things. It asks you for your database
631990	637830	credentials, then it asks you to create an initial administration account, and then you have
637830	645110	installed your application. What's notable is there's no authentication whatsoever. So these
645110	650810	installers have no protection, so everyone who, like if someone else calls this installer, he can
650810	659150	install it just as well. And this has been known for a while, like people have been using Google
659150	664310	to search for uninstalled WordPresses that have been abandoned, like maybe someone has
664310	668810	uploaded them and then a problem happened and they just forgot about this installation.
669530	672930	And if you find them with Google, then you can take them over.
676230	684030	But the new idea here is there's a small time window between when a webmaster uploads this
684030	690970	application and when he finishes the installation. And if we can hit that time window, we have an
690970	698070	attack, because then we can do the installation and then we are in control of this application.
700210	705790	And you might see where this is getting at. You may remember from earlier, we have this
705790	715730	feed of new host names. So if we combine these things, we have our attack. So we can monitor
715730	720850	the certificate transparency logs all the time, probably with some kind of con job,
721490	730770	automated, and extract all the host names. And then we check these hosts, like we do a
730770	735910	curl or a wget on them, and compare what they are currently serving as a web page
735910	743250	to common application installers from WordPress, from Joomla, from whatever.
743250	747570	So, and if you find one of them, we install this application ourselves.
747570	753590	And if we're a real attacker, we would probably do this automated. Of course, it's faster.
755290	759650	Now then, when we have done this installation, we can upload a plugin, because all these
759650	763670	applications usually have some kind of extension mechanism where you can upload a plugin, and
763670	771730	basically that gives you code execution. And ideally, we upload something that gives us
771730	776070	further code execution, so we can just then execute arbitrary code.
777410	782610	And what we do then is that we revert the installation, because how these installs work
782610	788490	is usually just when they finish, they write down a config file, and if we delete that config file,
788490	798220	then the installation is undone. So one thing we need for the whole thing are database credentials,
798220	803560	but that's not a problem, because you can just define an external MySQL host,
803880	808240	and there's, for example, a service called freemysqlhosting.net,
808240	814400	which offers free MySQL hosting, which is very convenient for what we're trying to do.
816920	820080	Yeah, so we have a little demo.
823840	827760	So what I'm doing here, this is the search engine I mentioned earlier,
829800	834720	and what I'm now doing is I put in a percent, which is a wildcard character,
834720	840360	and then I put in .tlsfun.de. That is one of my own domains.
842660	851820	And I'll make this a bit bigger. You see, the very latest entry here is for blog.tlsfun.de.
852240	856800	And let's just copy that URL and see what we can find there.
860180	867440	Oh, this is a WordPress installation. That is nice. So we click on continue,
867440	871440	and click another button. Okay, now we need these database credentials.
872160	876700	And as I'm prepared for this, I already have database credentials here,
877450	880660	as I said, from free MySQL hosting.
883420	900380	And password, and this host. Okay, run the install. So now I need a site title,
900380	908960	I just use test, username admin, want some password for me,
909580	913960	and an email. There, I just use something like trash mail.
916720	920620	And installation. Now it takes a bit...
924770	929290	Okay, so it says WordPress has been installed. Thank you and enjoy.
930210	936230	Login. So now I'm logging in with the admin account I just created with the password I just
936230	959680	typed in. Okay, and now I go in plugins, and click on add new. And so here I can just install
959680	965140	plugins from WordPress itself, but I can also click on upload plugin. So I can upload my own
965140	973380	plugin, which I have prepared before, which is called hijack, and we'll install it.
978560	990020	Okay, so now in this plugin, I have a file called shell.php, and it doesn't show me anything,
990020	997560	because it wants a secret. Secret is DEF CON 2017. It's not very exciting, but okay.
997560	1004280	Okay, and this is a very simple PHP shell. So we can make ls, and we can also...
1006400	1011360	Okay, now the screen is cut off. That's not very good. But I can show you, for example,
1011360	1016620	if I type in uname, then I get output of uname. So I basically have a shell now.
1019460	1024820	And the interesting thing is I also here have a button which says remove installation traces.
1025840	1030580	I'll just try to let you see that. Yeah, that's better.
1032980	1037320	And now if I go on this again,
1038920	1044600	then you see the installer's back. And that is important, because the person who is the owner
1044600	1050560	of this WordPress, which in this case is me, but in the real case is someone else, will never notice
1050560	1057260	what happened. So I have a backdoor now. I can execute arbitrary code on that server, but the
1057260	1066480	owner of that WordPress installation will never notice it. At least that's what we hope. Yeah.
1076660	1083520	So one challenge here that we have is that the certificates are not immediately public. There's
1083660	1091580	a time lag, which so it is a maximum two hours, but I have kind of measured it, and it's usually
1091580	1097780	about 30 minutes. So from certificate issuance until the certificate ends up in the lock.
1099480	1104420	But it doesn't really matter, because there are still like enough people who will just create
1104420	1109700	that host and then upload that WordPress and then go for a coffee and finish the installation later.
1109700	1118200	So we'll just hit enough vulnerable hosts in that time frame. And this could also be further
1118200	1123780	optimized, like you could say, I'm not only checking a site once, but when I see a new host
1123780	1129040	in the certificate transparency locks, I just check it every five minutes again and again for
1129040	1139460	maybe a couple of hours. So I ran a test script where I was searching for these installs
1139460	1144860	this certificate transparency locks over three months, and I could have taken over 5,000
1144860	1153900	WordPress installations in that time. So that's quite a nice spot net if you have 5,000 ways to
1153900	1160320	execute PHP code, use that to send spam or host phishing sites or whatever. Also around 500
1160320	1166140	Joomla installations, 120 next cloud and 70 on cloud. The others were all quite low, so the
1166140	1173040	others I would say probably doesn't deserve the effort. One thing is Drupal doesn't show up
1173040	1183800	because their installer page is so slow that the time out of my script hit. But yeah, that's just
1183800	1192600	kind of a technicality. So how can you protect against this? So in very general, I think these
1192600	1198340	installers need to be authenticated. I think it's just not a good design to say I upload an
1198340	1203160	installer and then it's just without any protection out there in the internet and we just hope
1203160	1212460	nobody finds it. The challenge is, of course, the developers of these applications, they want to
1212460	1217740	make the installation as easy as possible. And if you add any kind of authentication, that
1217740	1224640	creates extra effort. So I can kind of understand that they are reluctant, but still this somehow
1224640	1233660	needs to be fixed. So one thing you could imagine is that the installation process creates a secret
1233660	1239960	token, writes that into a file, and then the user has to download that file and paste that token
1239960	1245240	into a web form and only then he can install the application. That's one option, but of course
1245240	1253160	there are other options as well. So I reported this to a couple of vendors, primarily the big
1253160	1258360	content management systems because they are the most interesting here. So from Drupal,
1258360	1267040	Typo3, and OnCloud, I got no reaction at all. They just ignored my messages. Then from WordPress,
1267040	1273880	NextCloud, and Serendipity, there came some answers like we would like to discuss this with
1273880	1278700	other vendors and can we have a cross-vendor discussion. And I said, okay, I'll set up a
1278700	1291280	mailing list. But then there was not a whole lot of discussion. This is interesting. MediaWiki
1291280	1297920	is not vulnerable to it and was not even before I did this research. And the reason is their
1297920	1301720	installer works a bit different. So when you finish the installer, they don't just write the
1301720	1306620	config file, but they provide the config file for download. And you have to download it and
1306620	1311840	then upload it again to your web host. Otherwise, the installation doesn't get finished.
1313380	1320840	Although, MediaWiki allows you to use SQLite. And SQLite is file-based. So the installer still
1320840	1327200	kind of allows you to create a file on the server. But you don't have a whole lot of control over it.
1327810	1333280	I don't think this can be exploited, but it's a nice challenge. So if anyone of you
1333280	1337660	has an idea how to exploit that, I would be very interested to hear about that.
1340520	1346000	And then Joomla. Joomla was the only content management system that implemented a fix
1346000	1351880	after I reported it to them. They released it a couple of days ago. And what they're doing
1352780	1360180	is that it was basically my idea. The problem is I don't... I later decided that I don't like
1360180	1369180	the idea anymore. So what they're doing is they're whitelisting localhost as a MySQL server.
1369180	1375200	So if you have a local database server, the installation is just like it was before.
1375200	1381140	And if you have an external MySQL server, then they have an extra authentication step.
1381880	1388480	And the extra authentication step is that it has created a directory with a random file name,
1388480	1393040	and you're supposed to remove that directory, and then you can continue the installation.
1395000	1400220	So why don't I like it? So the problem here is if you have a large web hosting company that may
1400220	1406520	have thousands of customers on a single server, then it may just be that the attacker already
1406520	1412780	has credentials for that server. Like he can just register a couple of accounts at major
1412780	1418500	web hosting companies. Or you could even think one step further. The attacker is, of course,
1418500	1424040	attacking multiple applications at once, and WordPress is still vulnerable. So chances are
1424040	1429120	high he may have already hijacked one WordPress on that server when he finds that Joomla, and then
1429120	1435360	he can use the database credentials from that WordPress to hijack that Joomla. So I don't think
1435360	1439820	it's an ideal fix, but at least I have to give Joomla credit that they were the only ones that
1439820	1450030	did a fix at all. Like the others just didn't do anything. So what can you do as a user? If you
1450030	1457190	think now, okay, that's a problem. I don't want my WordPress to get hijacked before I even use it.
1457190	1468930	How can I protect myself? You could say, okay. As I said, these logs are not updated instantly,
1468930	1475850	so you have like 30 minutes, but it's kind of a bit risky because like there's no guarantee how
1475850	1481450	fast these logs are. And it could just be that next month Google decides they make a super fast
1481450	1486270	log because they have optimized their software and it's running much faster and then this doesn't
1486270	1492530	work anymore. So I don't think it's a very good solution, but yeah, you can think about that.
1494730	1501430	Then there's the thing called certificate reduction. So with this certificate transparency,
1501430	1507570	some certificate authorities were worried that, oh, that means all these host names are now public
1507570	1515420	and our customers might not like it. Particularly Symantec now already offers that. So there is a
1516270	1520790	part of certificate transparency where you can have redacted domain labels. So you could say
1520790	1527670	this certificate in the log is for redactedlabel.something.com.
1530070	1535890	But I don't think that's very practical either. So for one, as soon as the Google crawler sees
1535890	1542450	your real certificate, you're still again in the log. And the other thing is not all certificate
1542450	1549070	authorities offer this. And this has been quite controversial. So I'm not entirely sure if it's
1549070	1554310	going to stick around. And particularly if you had some web host that automatically issues
1554310	1560650	certificates for you, they are likely not going to use this. So it's also not a very good solution.
1560850	1565670	You can use a htaccess file to just password protect your installation.
1566230	1573470	That works. A problem is that some of these applications use htaccess themselves to configure
1573470	1579550	things. And you need to make sure that that doesn't interfere. For example, if you finish
1579690	1585270	a WordPress installation, it creates an htaccess file. And what you can however do is that you put
1585270	1593070	your password protection htaccess file in the upper directory. Because like Apache server
1593710	1601410	goes recursively through all the directories to scan for htaccess files. That doesn't work at all
1601410	1605890	web hosting environments because sometimes you only have write access in your web root.
1606010	1610530	But if you have write access in the upper directory, then you can do that. And that's
1610530	1615750	kind of the best you can do right now as long as these applications don't protect you.
1618110	1624570	So, yeah. Defending as a user is hard here. And we really need fixes from vendors here.
1628050	1634290	Then I was wondering, do attackers already use this? Does anyone know about this attack? Has
1634290	1640770	anyone had the same idea? And do they already exploit it? So, I sent a couple of posts with
1640770	1646530	just random subdomains from my domains and checked if anyone would access them. And okay,
1646530	1655450	my own test script would access them. That's obvious. And I also saw this in the log file
1656210	1662350	which says Netcraft survey agent. So, Netcraft is a company. I think they mainly do statistics
1662350	1669450	around the web. So, I think this is non-malicious. And it's also a good example that this data,
1669450	1673610	of course, it can be used for attacks, but it can also be used for legitimate proposals like
1673610	1679660	doing statistics, looking for new websites. That, I think, is legitimate use of that data.
1681010	1688850	So, I think nobody is exploiting this yet, but that may change. Yeah. So,
1688850	1695750	major takeaway, I think, is unauthenticated installs are a security risk. And I really think
1695750	1700770	these web applications need to do something about that and should fix this.
1703710	1709470	Then one thing, and I think that message many people haven't gotten yet, there are no more
1709470	1715610	secret host names, at least if you use HTTPS. So, if you ever had the idea in my company I could
1715610	1721730	have internal secret something something dot company name dot com and there's an internal
1721730	1728570	backend interface that nobody ever will find, forget about that. That has been a bad idea in
1728570	1733790	the past anyway, because host names are not encrypted, even if you use HTTPS, the host name
1733790	1742250	is always visible on the traffic, both through DNS and through server name indication. But now
1742870	1747770	it's a really broken assumption. So, if you have HTTPS for your web pages, you must assume that
1747770	1752450	the host names are public. And it's also interesting if you're maybe a pen tester or
1752450	1756950	looking at a bug bounty program, this is a good way to search for host names from companies.
1759110	1766250	And, yeah, final takeaway, certificate transparency is a valuable data source,
1766250	1773850	both for attackers and defenders. And I'd like to say something that I find important. So,
1773850	1778690	when I submitted this talk, I feared a bit that people might use this as an argument against
1778690	1784390	certificate transparency. And therefore I want to make very clear that I don't think it is. I think
1784390	1789890	certificate transparency is an amazing system. It's probably the best security improvement the
1789890	1796470	TLS ecosystem has seen in a while. And I think the problem really lies elsewhere. Certificate
1796470	1804350	transparency is just kind of amplifying the problem of unauthenticated installers here. So, yeah.
1806510	1813730	Yeah, I think it was pretty fast, so we should have time for some questions. Thank you.