[00:00.000 --> 00:05.700]  So today I'm going to explain to you how you can hijack a web application before it's even
[00:05.700 --> 00:13.140]  installed and use certificate transparency for that. So to get started, so you all know that
[00:13.140 --> 00:19.600]  we're using much more HTTPS these days, so there's a lot of effort to move the web to encrypted
[00:19.600 --> 00:26.000]  connections, like Google gives you a higher search ranking if your site is using HTTPS,
[00:26.000 --> 00:29.220]  and there have been initiatives like Let's Encrypt to make it easier.
[00:29.820 --> 00:34.880]  So yeah, so HTTPS is a very important piece of modern web security.
[00:36.480 --> 00:42.520]  And part of that is certificate authorities. So if you want to run a web page with HTTPS,
[00:42.520 --> 00:47.160]  you need a certificate and that needs to be signed by one of these certificate authorities.
[00:47.480 --> 00:51.580]  And here are some of the bigger ones, like Komodo, Symantec, and Let's Encrypt,
[00:51.580 --> 00:59.200]  which is like a new and free one. And one question that comes up quite often is,
[00:59.200 --> 01:04.560]  do we trust certificate authorities? And for many people, the answer to that question is just,
[01:04.560 --> 01:09.600]  no, we cannot trust them. Because like there have been a lot of incidents in the past where
[01:09.600 --> 01:14.820]  certificate authorities have issued certificates for domains where they haven't been asked for,
[01:14.820 --> 01:23.340]  or even for rogue purposes for attacking people. So many people don't trust the system very much.
[01:24.800 --> 01:31.260]  And something I hear very often is that people say, yeah, this whole system is broken. We need
[01:31.260 --> 01:37.280]  to get rid of it. We need to completely replace that with something else. That's something I hear
[01:37.280 --> 01:43.640]  very often, especially in the IT security community. The problem, however, with that is
[01:43.640 --> 01:48.840]  in reality, I think nobody really has a plan with what to replace certificate authorities,
[01:48.840 --> 01:56.820]  or at least not any plan that is realistically feasible. And so what has been happening a lot
[01:56.820 --> 02:00.940]  in the past couple of years that people have thought, how can we improve this system? How
[02:00.940 --> 02:06.840]  can we make the existing system more secure? One thing that has happened is the so-called
[02:06.840 --> 02:13.080]  baseline requirements. So that's just a document that is writing down the rules under which these
[02:13.080 --> 02:19.580]  certificate authorities operate. So how they should issue certificates, how they should check
[02:20.200 --> 02:25.060]  that a domain really belongs to the domain owner. And that's already improving a lot,
[02:25.060 --> 02:30.420]  because if something strange is going on and the certificate authority is doing things that it
[02:30.420 --> 02:34.880]  probably shouldn't do, then there's probably something in the baseline requirements where
[02:34.880 --> 02:41.940]  you can say, hey, here's a rule that's not allowed. Then there's a technology called
[02:41.940 --> 02:47.580]  HTTP public key pinning, which is a very strong protection, but it's also kind of dangerous,
[02:47.580 --> 02:55.920]  because you could pin your site to a key and then lose the key. So this is a very strong
[02:55.920 --> 03:02.080]  technology, but you probably shouldn't use it unless you know exactly what you're doing.
[03:03.100 --> 03:09.700]  One other thing is called CAA, certificate authority authorization. What's happening
[03:09.700 --> 03:15.400]  there is that you can define a DNS record which is saying, I only want certificates from this
[03:15.400 --> 03:22.500]  specific certificate authority and not from any other. And then there's this thing called
[03:22.500 --> 03:31.700]  certificate transparency, which will be the main topic of my talk. And the idea here is that we
[03:31.700 --> 03:38.720]  have public logs of certificates. So all the certificates, we put them in a log that is also
[03:38.720 --> 03:45.340]  verifiable in some cryptographic sense. So there's more transparency in that system so that
[03:45.340 --> 03:53.880]  people can watch what's going on. So I'm not going to talk about the details of how that works. So
[03:53.880 --> 04:02.660]  there's a lot of fancy crypto. There are a lot of acronyms like signed certificate timestamps,
[04:03.080 --> 04:12.380]  etc. The basic idea is all of that is to prevent cheating in that system. So the idea is to make
[04:12.380 --> 04:20.420]  it really hard for any actor in the system, whether it's a certificate authority or log operator,
[04:20.420 --> 04:28.640]  to make something appear like it isn't really. So these logs have some cryptographic integrity
[04:28.640 --> 04:34.760]  and it is very hard to log something and then remove it again from the log without that being
[04:34.760 --> 04:47.240]  noted. So right now this is not fully implemented, but starting next year, at least according to the
[04:47.240 --> 04:52.860]  current plan, this has been changed. But according to the current plan, next year in April, there
[04:52.860 --> 04:58.040]  will be a requirement for all new certificates that they need to be submitted to at least two
[04:58.040 --> 05:07.500]  of these public logs. But in practice today, a lot of certificates are already logged and there
[05:07.500 --> 05:13.260]  are a number of reasons for that. So there are some certificate authorities that already submit
[05:13.260 --> 05:18.240]  their certificates to logs. One of them is Symantec and they do it because Google said
[05:18.240 --> 05:24.020]  they have to do it because there were a lot of issues with Symantec in the past. Let's Encrypt
[05:24.020 --> 05:28.380]  is doing it voluntarily because they say they want to support this. They think this is a good
[05:28.380 --> 05:34.600]  system. Also Cloudflare is doing it, so if you register a Cloudflare site, you automatically get
[05:34.600 --> 05:40.420]  HTTPS and they submit the certificates to logs. And also the Google search engine crawler, so
[05:40.420 --> 05:45.780]  if the crawler from the Google search engine surfs to your site and you have HTTPS,
[05:45.780 --> 05:49.080]  then they will download the certificate and submit it to their logs.
[05:49.800 --> 05:58.120]  So in practice, that means already today, a lot of certificates are in these logs and get
[05:58.120 --> 06:05.620]  submitted pretty quickly to these logs. So you can think of certificate transparency a bit like
[06:05.780 --> 06:11.860]  a CA watchdog. So everyone can look into these logs and see if there's anything that looks in
[06:11.860 --> 06:17.720]  any way suspicious. So the most obvious thing is to look into these logs if there are certificates
[06:17.720 --> 06:24.260]  for your own domains that you haven't ordered yourself. So if there's a certificate for my
[06:24.260 --> 06:30.180]  domain and I don't know about it, then something is wrong. That's obvious. But there's also things
[06:30.180 --> 06:36.200]  like if you look at this certificate, what's a bit suspicious here is that it's only valid for
[06:36.200 --> 06:45.140]  one day and it's for Google com. That was an internal test at Symantec. Apparently they have
[06:45.140 --> 06:50.780]  submitted the certificate from the internal test to the public log. So Google found out about it.
[06:50.780 --> 06:57.000]  So it's a certificate for Google com, but it's not from Google. So that started the whole
[06:57.000 --> 07:08.420]  Symantec controversy. This is also interesting. So does anyone see what's wrong here?
[07:08.420 --> 07:17.610]  So if you look at the location, it says it's in Rotterdam in California in the Netherlands.
[07:19.010 --> 07:25.650]  So I don't know about your geography skills, but California is, as far as I know,
[07:25.650 --> 07:32.790]  not part of the Netherlands. Maybe there are some similarities, but yeah.
[07:34.010 --> 07:39.110]  This one is also interesting. So here you can see in one of the lower lines, there's a domain
[07:39.110 --> 07:46.910]  name with two dots in it. So it says dot dot this, and that's not a valid host name. So we can
[07:46.910 --> 07:53.250]  be sure that there's no way anyone has really checked that this host name belongs to anyone
[07:53.250 --> 08:02.970]  because it's an invalid host name. It cannot belong to anyone. So here you can see that this
[08:02.970 --> 08:07.730]  system really works. People are looking at these logs and are seeing, okay, here's something
[08:07.730 --> 08:14.830]  strange, here's something fishy, and we should report that, and yeah. And hopefully then the CA
[08:14.830 --> 08:22.410]  will not do it again in the future. If you want to check this out a bit, there's a search engine
[08:22.410 --> 08:28.910]  for certificates and certificate transparency under your LCRTSH. That's very nice. That's
[08:28.910 --> 08:35.370]  operated by Komodo. So for example, the very easiest thing you could do right now is search
[08:35.370 --> 08:42.230]  if there are certificates for your domain that you don't know. But on the other hand,
[08:42.230 --> 08:49.010]  certificate transparency is also a kind of data source. Because we have all these certificates,
[08:49.010 --> 08:53.370]  okay, for example, they contain, as we have seen sometimes, the location and also they contain
[08:53.370 --> 08:59.170]  host names. So for example, if you operate a search engine, this could be interesting because
[08:59.170 --> 09:04.830]  you could know, okay, here are all these hosts that have web pages, so maybe I look at them.
[09:07.810 --> 09:14.890]  So in a certain sense, certificate transparency gives you a kind of feed for new host names.
[09:14.990 --> 09:20.430]  So if you're permanently observing these logs as they are public, like there's an API,
[09:20.430 --> 09:25.550]  you can just simply request the new certificates from them, and then you can look into these
[09:25.550 --> 09:31.650]  certificates and see host names. And when someone creates a new web host with HTTPS and gets a
[09:31.650 --> 09:37.010]  certificate, then it will end up in logs, so you kind of have a feed of new web host names.
[09:38.530 --> 09:44.430]  So now I want to switch the topic a bit to something which may appear like something
[09:44.430 --> 09:50.550]  completely unrelated at first, and that's web applications. And when I talk about web
[09:50.550 --> 09:56.390]  applications here, I mean things like self-hosted web applications. So things like WordPress,
[09:56.390 --> 10:03.870]  Joomla, or things like Nextcloud. These are usually written in PHP, usually use MySQL,
[10:03.870 --> 10:10.110]  you probably all know one of these like typical content management systems and similar things.
[10:10.830 --> 10:18.510]  When you install one of those, what usually happens, so you upload the files from the
[10:18.510 --> 10:26.230]  software to some web hosting company or on your own server, and then usually you just call the
[10:26.230 --> 10:31.990]  web page and get an installer and click through a few things. It asks you for your database
[10:31.990 --> 10:37.830]  credentials, then it asks you to create an initial administration account, and then you have
[10:37.830 --> 10:45.110]  installed your application. What's notable is there's no authentication whatsoever. So these
[10:45.110 --> 10:50.810]  installers have no protection, so everyone who, like if someone else calls this installer, he can
[10:50.810 --> 10:59.150]  install it just as well. And this has been known for a while, like people have been using Google
[10:59.150 --> 11:04.310]  to search for uninstalled WordPresses that have been abandoned, like maybe someone has
[11:04.310 --> 11:08.810]  uploaded them and then a problem happened and they just forgot about this installation.
[11:09.530 --> 11:12.930]  And if you find them with Google, then you can take them over.
[11:16.230 --> 11:24.030]  But the new idea here is there's a small time window between when a webmaster uploads this
[11:24.030 --> 11:30.970]  application and when he finishes the installation. And if we can hit that time window, we have an
[11:30.970 --> 11:38.070]  attack, because then we can do the installation and then we are in control of this application.
[11:40.210 --> 11:45.790]  And you might see where this is getting at. You may remember from earlier, we have this
[11:45.790 --> 11:55.730]  feed of new host names. So if we combine these things, we have our attack. So we can monitor
[11:55.730 --> 12:00.850]  the certificate transparency logs all the time, probably with some kind of con job,
[12:01.490 --> 12:10.770]  automated, and extract all the host names. And then we check these hosts, like we do a
[12:10.770 --> 12:15.910]  curl or a wget on them, and compare what they are currently serving as a web page
[12:15.910 --> 12:23.250]  to common application installers from WordPress, from Joomla, from whatever.
[12:23.250 --> 12:27.570]  So, and if you find one of them, we install this application ourselves.
[12:27.570 --> 12:33.590]  And if we're a real attacker, we would probably do this automated. Of course, it's faster.
[12:35.290 --> 12:39.650]  Now then, when we have done this installation, we can upload a plugin, because all these
[12:39.650 --> 12:43.670]  applications usually have some kind of extension mechanism where you can upload a plugin, and
[12:43.670 --> 12:51.730]  basically that gives you code execution. And ideally, we upload something that gives us
[12:51.730 --> 12:56.070]  further code execution, so we can just then execute arbitrary code.
[12:57.410 --> 13:02.610]  And what we do then is that we revert the installation, because how these installs work
[13:02.610 --> 13:08.490]  is usually just when they finish, they write down a config file, and if we delete that config file,
[13:08.490 --> 13:18.220]  then the installation is undone. So one thing we need for the whole thing are database credentials,
[13:18.220 --> 13:23.560]  but that's not a problem, because you can just define an external MySQL host,
[13:23.880 --> 13:28.240]  and there's, for example, a service called freemysqlhosting.net,
[13:28.240 --> 13:34.400]  which offers free MySQL hosting, which is very convenient for what we're trying to do.
[13:36.920 --> 13:40.080]  Yeah, so we have a little demo.
[13:43.840 --> 13:47.760]  So what I'm doing here, this is the search engine I mentioned earlier,
[13:49.800 --> 13:54.720]  and what I'm now doing is I put in a percent, which is a wildcard character,
[13:54.720 --> 14:00.360]  and then I put in .tlsfun.de. That is one of my own domains.
[14:02.660 --> 14:11.820]  And I'll make this a bit bigger. You see, the very latest entry here is for blog.tlsfun.de.
[14:12.240 --> 14:16.800]  And let's just copy that URL and see what we can find there.
[14:20.180 --> 14:27.440]  Oh, this is a WordPress installation. That is nice. So we click on continue,
[14:27.440 --> 14:31.440]  and click another button. Okay, now we need these database credentials.
[14:32.160 --> 14:36.700]  And as I'm prepared for this, I already have database credentials here,
[14:37.450 --> 14:40.660]  as I said, from free MySQL hosting.
[14:43.420 --> 15:00.380]  And password, and this host. Okay, run the install. So now I need a site title,
[15:00.380 --> 15:08.960]  I just use test, username admin, want some password for me,
[15:09.580 --> 15:13.960]  and an email. There, I just use something like trash mail.
[15:16.720 --> 15:20.620]  And installation. Now it takes a bit...
[15:24.770 --> 15:29.290]  Okay, so it says WordPress has been installed. Thank you and enjoy.
[15:30.210 --> 15:36.230]  Login. So now I'm logging in with the admin account I just created with the password I just
[15:36.230 --> 15:59.680]  typed in. Okay, and now I go in plugins, and click on add new. And so here I can just install
[15:59.680 --> 16:05.140]  plugins from WordPress itself, but I can also click on upload plugin. So I can upload my own
[16:05.140 --> 16:13.380]  plugin, which I have prepared before, which is called hijack, and we'll install it.
[16:18.560 --> 16:30.020]  Okay, so now in this plugin, I have a file called shell.php, and it doesn't show me anything,
[16:30.020 --> 16:37.560]  because it wants a secret. Secret is DEF CON 2017. It's not very exciting, but okay.
[16:37.560 --> 16:44.280]  Okay, and this is a very simple PHP shell. So we can make ls, and we can also...
[16:46.400 --> 16:51.360]  Okay, now the screen is cut off. That's not very good. But I can show you, for example,
[16:51.360 --> 16:56.620]  if I type in uname, then I get output of uname. So I basically have a shell now.
[16:59.460 --> 17:04.820]  And the interesting thing is I also here have a button which says remove installation traces.
[17:05.840 --> 17:10.580]  I'll just try to let you see that. Yeah, that's better.
[17:12.980 --> 17:17.320]  And now if I go on this again,
[17:18.920 --> 17:24.600]  then you see the installer's back. And that is important, because the person who is the owner
[17:24.600 --> 17:30.560]  of this WordPress, which in this case is me, but in the real case is someone else, will never notice
[17:30.560 --> 17:37.260]  what happened. So I have a backdoor now. I can execute arbitrary code on that server, but the
[17:37.260 --> 17:46.480]  owner of that WordPress installation will never notice it. At least that's what we hope. Yeah.
[17:56.660 --> 18:03.520]  So one challenge here that we have is that the certificates are not immediately public. There's
[18:03.660 --> 18:11.580]  a time lag, which so it is a maximum two hours, but I have kind of measured it, and it's usually
[18:11.580 --> 18:17.780]  about 30 minutes. So from certificate issuance until the certificate ends up in the lock.
[18:19.480 --> 18:24.420]  But it doesn't really matter, because there are still like enough people who will just create
[18:24.420 --> 18:29.700]  that host and then upload that WordPress and then go for a coffee and finish the installation later.
[18:29.700 --> 18:38.200]  So we'll just hit enough vulnerable hosts in that time frame. And this could also be further
[18:38.200 --> 18:43.780]  optimized, like you could say, I'm not only checking a site once, but when I see a new host
[18:43.780 --> 18:49.040]  in the certificate transparency locks, I just check it every five minutes again and again for
[18:49.040 --> 18:59.460]  maybe a couple of hours. So I ran a test script where I was searching for these installs
[18:59.460 --> 19:04.860]  this certificate transparency locks over three months, and I could have taken over 5,000
[19:04.860 --> 19:13.900]  WordPress installations in that time. So that's quite a nice spot net if you have 5,000 ways to
[19:13.900 --> 19:20.320]  execute PHP code, use that to send spam or host phishing sites or whatever. Also around 500
[19:20.320 --> 19:26.140]  Joomla installations, 120 next cloud and 70 on cloud. The others were all quite low, so the
[19:26.140 --> 19:33.040]  others I would say probably doesn't deserve the effort. One thing is Drupal doesn't show up
[19:33.040 --> 19:43.800]  because their installer page is so slow that the time out of my script hit. But yeah, that's just
[19:43.800 --> 19:52.600]  kind of a technicality. So how can you protect against this? So in very general, I think these
[19:52.600 --> 19:58.340]  installers need to be authenticated. I think it's just not a good design to say I upload an
[19:58.340 --> 20:03.160]  installer and then it's just without any protection out there in the internet and we just hope
[20:03.160 --> 20:12.460]  nobody finds it. The challenge is, of course, the developers of these applications, they want to
[20:12.460 --> 20:17.740]  make the installation as easy as possible. And if you add any kind of authentication, that
[20:17.740 --> 20:24.640]  creates extra effort. So I can kind of understand that they are reluctant, but still this somehow
[20:24.640 --> 20:33.660]  needs to be fixed. So one thing you could imagine is that the installation process creates a secret
[20:33.660 --> 20:39.960]  token, writes that into a file, and then the user has to download that file and paste that token
[20:39.960 --> 20:45.240]  into a web form and only then he can install the application. That's one option, but of course
[20:45.240 --> 20:53.160]  there are other options as well. So I reported this to a couple of vendors, primarily the big
[20:53.160 --> 20:58.360]  content management systems because they are the most interesting here. So from Drupal,
[20:58.360 --> 21:07.040]  Typo3, and OnCloud, I got no reaction at all. They just ignored my messages. Then from WordPress,
[21:07.040 --> 21:13.880]  NextCloud, and Serendipity, there came some answers like we would like to discuss this with
[21:13.880 --> 21:18.700]  other vendors and can we have a cross-vendor discussion. And I said, okay, I'll set up a
[21:18.700 --> 21:31.280]  mailing list. But then there was not a whole lot of discussion. This is interesting. MediaWiki
[21:31.280 --> 21:37.920]  is not vulnerable to it and was not even before I did this research. And the reason is their
[21:37.920 --> 21:41.720]  installer works a bit different. So when you finish the installer, they don't just write the
[21:41.720 --> 21:46.620]  config file, but they provide the config file for download. And you have to download it and
[21:46.620 --> 21:51.840]  then upload it again to your web host. Otherwise, the installation doesn't get finished.
[21:53.380 --> 22:00.840]  Although, MediaWiki allows you to use SQLite. And SQLite is file-based. So the installer still
[22:00.840 --> 22:07.200]  kind of allows you to create a file on the server. But you don't have a whole lot of control over it.
[22:07.810 --> 22:13.280]  I don't think this can be exploited, but it's a nice challenge. So if anyone of you
[22:13.280 --> 22:17.660]  has an idea how to exploit that, I would be very interested to hear about that.
[22:20.520 --> 22:26.000]  And then Joomla. Joomla was the only content management system that implemented a fix
[22:26.000 --> 22:31.880]  after I reported it to them. They released it a couple of days ago. And what they're doing
[22:32.780 --> 22:40.180]  is that it was basically my idea. The problem is I don't... I later decided that I don't like
[22:40.180 --> 22:49.180]  the idea anymore. So what they're doing is they're whitelisting localhost as a MySQL server.
[22:49.180 --> 22:55.200]  So if you have a local database server, the installation is just like it was before.
[22:55.200 --> 23:01.140]  And if you have an external MySQL server, then they have an extra authentication step.
[23:01.880 --> 23:08.480]  And the extra authentication step is that it has created a directory with a random file name,
[23:08.480 --> 23:13.040]  and you're supposed to remove that directory, and then you can continue the installation.
[23:15.000 --> 23:20.220]  So why don't I like it? So the problem here is if you have a large web hosting company that may
[23:20.220 --> 23:26.520]  have thousands of customers on a single server, then it may just be that the attacker already
[23:26.520 --> 23:32.780]  has credentials for that server. Like he can just register a couple of accounts at major
[23:32.780 --> 23:38.500]  web hosting companies. Or you could even think one step further. The attacker is, of course,
[23:38.500 --> 23:44.040]  attacking multiple applications at once, and WordPress is still vulnerable. So chances are
[23:44.040 --> 23:49.120]  high he may have already hijacked one WordPress on that server when he finds that Joomla, and then
[23:49.120 --> 23:55.360]  he can use the database credentials from that WordPress to hijack that Joomla. So I don't think
[23:55.360 --> 23:59.820]  it's an ideal fix, but at least I have to give Joomla credit that they were the only ones that
[23:59.820 --> 24:10.030]  did a fix at all. Like the others just didn't do anything. So what can you do as a user? If you
[24:10.030 --> 24:17.190]  think now, okay, that's a problem. I don't want my WordPress to get hijacked before I even use it.
[24:17.190 --> 24:28.930]  How can I protect myself? You could say, okay. As I said, these logs are not updated instantly,
[24:28.930 --> 24:35.850]  so you have like 30 minutes, but it's kind of a bit risky because like there's no guarantee how
[24:35.850 --> 24:41.450]  fast these logs are. And it could just be that next month Google decides they make a super fast
[24:41.450 --> 24:46.270]  log because they have optimized their software and it's running much faster and then this doesn't
[24:46.270 --> 24:52.530]  work anymore. So I don't think it's a very good solution, but yeah, you can think about that.
[24:54.730 --> 25:01.430]  Then there's the thing called certificate reduction. So with this certificate transparency,
[25:01.430 --> 25:07.570]  some certificate authorities were worried that, oh, that means all these host names are now public
[25:07.570 --> 25:15.420]  and our customers might not like it. Particularly Symantec now already offers that. So there is a
[25:16.270 --> 25:20.790]  part of certificate transparency where you can have redacted domain labels. So you could say
[25:20.790 --> 25:27.670]  this certificate in the log is for redactedlabel.something.com.
[25:30.070 --> 25:35.890]  But I don't think that's very practical either. So for one, as soon as the Google crawler sees
[25:35.890 --> 25:42.450]  your real certificate, you're still again in the log. And the other thing is not all certificate
[25:42.450 --> 25:49.070]  authorities offer this. And this has been quite controversial. So I'm not entirely sure if it's
[25:49.070 --> 25:54.310]  going to stick around. And particularly if you had some web host that automatically issues
[25:54.310 --> 26:00.650]  certificates for you, they are likely not going to use this. So it's also not a very good solution.
[26:00.850 --> 26:05.670]  You can use a htaccess file to just password protect your installation.
[26:06.230 --> 26:13.470]  That works. A problem is that some of these applications use htaccess themselves to configure
[26:13.470 --> 26:19.550]  things. And you need to make sure that that doesn't interfere. For example, if you finish
[26:19.690 --> 26:25.270]  a WordPress installation, it creates an htaccess file. And what you can however do is that you put
[26:25.270 --> 26:33.070]  your password protection htaccess file in the upper directory. Because like Apache server
[26:33.710 --> 26:41.410]  goes recursively through all the directories to scan for htaccess files. That doesn't work at all
[26:41.410 --> 26:45.890]  web hosting environments because sometimes you only have write access in your web root.
[26:46.010 --> 26:50.530]  But if you have write access in the upper directory, then you can do that. And that's
[26:50.530 --> 26:55.750]  kind of the best you can do right now as long as these applications don't protect you.
[26:58.110 --> 27:04.570]  So, yeah. Defending as a user is hard here. And we really need fixes from vendors here.
[27:08.050 --> 27:14.290]  Then I was wondering, do attackers already use this? Does anyone know about this attack? Has
[27:14.290 --> 27:20.770]  anyone had the same idea? And do they already exploit it? So, I sent a couple of posts with
[27:20.770 --> 27:26.530]  just random subdomains from my domains and checked if anyone would access them. And okay,
[27:26.530 --> 27:35.450]  my own test script would access them. That's obvious. And I also saw this in the log file
[27:36.210 --> 27:42.350]  which says Netcraft survey agent. So, Netcraft is a company. I think they mainly do statistics
[27:42.350 --> 27:49.450]  around the web. So, I think this is non-malicious. And it's also a good example that this data,
[27:49.450 --> 27:53.610]  of course, it can be used for attacks, but it can also be used for legitimate proposals like
[27:53.610 --> 27:59.660]  doing statistics, looking for new websites. That, I think, is legitimate use of that data.
[28:01.010 --> 28:08.850]  So, I think nobody is exploiting this yet, but that may change. Yeah. So,
[28:08.850 --> 28:15.750]  major takeaway, I think, is unauthenticated installs are a security risk. And I really think
[28:15.750 --> 28:20.770]  these web applications need to do something about that and should fix this.
[28:23.710 --> 28:29.470]  Then one thing, and I think that message many people haven't gotten yet, there are no more
[28:29.470 --> 28:35.610]  secret host names, at least if you use HTTPS. So, if you ever had the idea in my company I could
[28:35.610 --> 28:41.730]  have internal secret something something dot company name dot com and there's an internal
[28:41.730 --> 28:48.570]  backend interface that nobody ever will find, forget about that. That has been a bad idea in
[28:48.570 --> 28:53.790]  the past anyway, because host names are not encrypted, even if you use HTTPS, the host name
[28:53.790 --> 29:02.250]  is always visible on the traffic, both through DNS and through server name indication. But now
[29:02.870 --> 29:07.770]  it's a really broken assumption. So, if you have HTTPS for your web pages, you must assume that
[29:07.770 --> 29:12.450]  the host names are public. And it's also interesting if you're maybe a pen tester or
[29:12.450 --> 29:16.950]  looking at a bug bounty program, this is a good way to search for host names from companies.
[29:19.110 --> 29:26.250]  And, yeah, final takeaway, certificate transparency is a valuable data source,
[29:26.250 --> 29:33.850]  both for attackers and defenders. And I'd like to say something that I find important. So,
[29:33.850 --> 29:38.690]  when I submitted this talk, I feared a bit that people might use this as an argument against
[29:38.690 --> 29:44.390]  certificate transparency. And therefore I want to make very clear that I don't think it is. I think
[29:44.390 --> 29:49.890]  certificate transparency is an amazing system. It's probably the best security improvement the
[29:49.890 --> 29:56.470]  TLS ecosystem has seen in a while. And I think the problem really lies elsewhere. Certificate
[29:56.470 --> 30:04.350]  transparency is just kind of amplifying the problem of unauthenticated installers here. So, yeah.
[30:06.510 --> 30:13.730]  Yeah, I think it was pretty fast, so we should have time for some questions. Thank you.