 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 high search ranking if you're just using HTTPS and there have been initiatives like Glets and Crypt to make it easier. 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 Glets and Crypt which is like a new and free one. And one question that comes up quite often is how much can we trust these 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 this 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 the certificate authorities operate. And yeah, 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 that 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 locks of certificates. So all the certificates we put them in a lock that is also very filable 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 Macla hash freeze used and you get a lot of acronyms like science certificate timestamps, science tree heads, et cetera. 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 a lock operator to make something appear like it isn't really. So these locks have some cryptographic integrity and it is very hard to like lock something and then remove it again from the lock without that being noted. And 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 locks. But in practice today a lot of certificates are already locked and there are a number of reasons for that. So for example there are some certificate authorities that already submit their certificates to locks. 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 locks 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 locks. So in practice that means already today a lot of certificates are in these locks and get submitted pretty quickly to these locks. So you can think of certificate transparency like a bit like a CA watchdog. So everyone can look into these locks and see if there is anything that looks in any way suspicious. So the most obvious thing is to look into these locks if there are certificates for your own domains that you haven't ordered yourself. So if there is a certificate from my domain and I don't know about it then something is wrong. That's obvious. But there are 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 Googlecom. That was an internal test at Symantec. Apparently they have still submitted the certificate from their internal test to the public lock. So Google found out about it. So it's a certificate for Googlecom but it is not from Google. So that started the whole Symantec controversy. And this is also interesting. So does anyone see what's wrong here? So if you look at the location it says that 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 is 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. Like people are looking at these locks and are seeing okay here's something strange, here's something fishy and we should report that 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 in certificate transparency on the URL CRTSH. That's very nice. That's operated by Komodo. So for example the very easiest thing you could do right now is search there 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 like 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 locks as they are public like there's an API you can 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 lock so you kind of have a feed of new web host names. So and 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, things like Jumla, or things like Next Cloud. These are usually written in PHP, usually use MySQL. You probably all know one of these 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 that 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. So and this has been known for a while like people have been using Google to search for uninstalled word presses 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. So but the new idea here is there is 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. So 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 drop with a script automated and extract all the host names. And then we check these hosts like we do a curl or a W get on them and compare what they are currently serving as a web page to common application installers from word press from from whatever. So and if you find one of them we install this application ourselves and if we are a real attacker we will probably do this automated of course it's faster. Now then when we have done this installation we can upload a plug in because all these applications usually have some kind of extension mechanism where you can upload a plug in and basically that gives you code execution. And we 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 like 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 from 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 freeMySQL hosting.net which offers free MySQL hosting which is very convenient for what we are trying to do. Yeah, so we have a little demo. So what I'm doing here this is the search engine I mentioned earlier. So and what I'm now doing is like I put in a percent which is a wild card 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 like the very latest entry here is for block.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. I 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 this host. Okay, run the install. So now I need a site title where I just use test. I use an admin. Want some password from me. And an email. There I just use something a trash mail. And installation. Now it takes a bit. Okay. So it is .tlsfun. Thank you and enjoy. Log in. 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 on plugins. And click on add new. And 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 DevCon 2017. It's not very exciting but okay. Okay. And this is a very simple PHP shell. So we can make LS. 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 new name then I get output of new name. So I basically have a shell now. And the interesting thing is I also here have a button which says remove installation crisis. 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 spec. 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 back door 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. That was the demo. 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 till 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 timeframe. 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 installers with 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 dream line installations, 120 next cloud and 70 on cloud. The others were all quite low so the others I would say it 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. So, but yeah, that's just kind of a technicality. So how can we 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 insert the application. That's one option but of course there are the 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 Utupa, Type 3 and onCloud I got no reaction at all. They just ignored my messages. Then from WordPress, NextCloud and Serendipity they said so there were some, there came some answers like we would like to discuss this with other vendors and can you kind of, 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. So this is interesting. MediaViki 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 their 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 MediaViki 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 so 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 are doing is that it was basically my idea, the problem is I later decided that I don't like the idea anymore. So what they are doing is they are wide listing local host as a SQL 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 are 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 you 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 JUMLA and then he can use the database credentials from that WordPress to hijack that JUMLA. So I don't think it's an ideal fix but at least I have to give JUMLA 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? Like 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 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 redacted label.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 it's also this has been quite controversial. So I'm not entirely sure if it's going to stick around and particularly if you had some white posts that automatically issue certificates for you they are likely not going to use this. So it's also not a very good solution. You couldn't use a HT access file to just password protect your installation. That works. A problem is that some of these applications use HT access themselves to configure things and you need to make sure that that doesn't interfere. Like for example if you finish a WordPress installation it creates an HT access file. And what you can however do is that you put your password protection HT access file in the upper directory because like a patchy server goes recursively through all the directories to scan for HT access files. That doesn't work at all web hosting environments because sometimes you only have right access in your web route but if you have right 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 sub domains from my domains and checked if anyone would access them. And okay of course my own test script would access them. That's obvious. And I also saw this in the log file which says net craft survey agent. So net craft 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 like 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 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 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 looking at bug bounty program this is a good way to search for host names from companies. And yeah final takeaway like 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 feel 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. Like I think certificate of 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 here lies elsewhere. Certificate transparency is just kind of amplifying the problem of unauthenticated installers here. So yeah. Yeah I think I was pretty fast so we should have time for some questions. Thank you.