>>So today I’m going to explain to you how you can hijack your web application before it’s even installed and use certification 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. Um and uh 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 the certificate authorities and here are some of the bigger ones like Comodo, Symantec, and Let’s Encrypt which is like a new and free one. [yelling from crowd] Umm 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. Uh 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 ill purposes for attacking people um so many people don't trust the system very much. And uh some thing 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.” Um that’s something I hear very often eh especially in the IT security community. Umm the problem however with that is uh in reality I think nobody really has a plan with what to replace the certificate authorities or at least not any plan that is realistically feasible. Um and so what has been happening a lot in the past couple of years that people have thought have can we improve this system? How can we make the existing system more secure? Um 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 uh yeah so how they should issue certificates how the che- check uh that a domain really belongs to the domain owner. And that’s already improving a lot because if 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 is a rule that's not allowed.” Um then there's uh uh technology called HTTP public key pinning which is a very strong protection but it's also kind of dangerous uh because you could pin your site to a key that then and then lose the key so this is uh a very strong technology but it it you probably shouldn’t use it unless you know exactly what you’re doing. Um one other thing is called CAA uh certificate authority authorization what’s happening there is that you can define a DNS record which saying “I only want certificates from this specific certificate authority and not from any other.” Um and then there’s this thing called certificate transparency which will be the main topic of my talk. Um and the idea here is that we have public logs of certificates so all the certificates we put them in a log eh 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. Um so I’m not gonna talk about the details of how that works so there’s a lot of fancy crypto there, Merkle Hash Trees use, then you you get a lot of acronyms like Science Certificate Timestamps, Signed Tree Heads et cetera um. The basic idea is all of that is uh to prevent cheating in that system. So the idea is to make it really hard to to for for any actor in the system whether it's a certificate authority or a log operator to to make something appear like it isn't’ really. So so this for example so these, these logs have some cryptographic integrity and it is very hard to like log something and then remove it again from the log without that being noted. Um um and uh so right now this is uh not fully implemented but starting next year at least according to the current plan this has been changed, uh 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. Um but in practice today a lot of certificates are already logged, uh and there are a number of reasons for that. So for example there are some certificate authorities that already submit their certificates to logs, uh 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. Uh Let’s Encrypt is doing it voluntarily because they say they want to support this they think this is a good system. Um also CloudFlare is doing it so if you’re registered CloudFlare side you automatically get a 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 would honor the certificate and submit it to their logs. So eh um yeah so in practice that means ah-already today a lot of certificates are in these logs and are get submitted pretty quickly to these logs. Um so you can think of certificate transparency like 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 they answer 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 um what’s a bit suspicious here is that it’s only valid for one day. And it’s for Google com. Um that was an internal test at Symantec uh apparently they have still 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 is not from Google so that started the whole Symantec controversy. Um and this is also interesting. So um uh does anyone see what's wrong here? [crowd yelling] So if you look at the location it says that’s in in Rotterdam in California in the Netherlands. [crowd laughs] So I don’t know about your geography skills but um California is as far as I know not part of the Netherlands. [laughter] Um maybe there are some similarities but uh yeah. Um 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 biz and that’s not a valid host name. So we we can be sure that there’s no way anyone has really checked that this hostname eh- that belongs to anyone because it's an invalid host name. It cannot belong to anyone. So so here you can see like uh uh but but this the system really works. Like people are looking at these logs and they’re seeing ok here is something strange here is something fishy uh and we should report that. And yeah. And hopefully then the CA will not do it again in the future. Um if you want to check this out a bit there’s a search engine for certificates and certificate transparency under your LC or TSH. That’s very nice that’s operated by Comodo. Um 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 about. Umm but on the other hand certificate transparencies also are kind of data source. Because like we have all the certificates. Ok so 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 here ok here are all of these theses hosts that have web pages so maybe I look at them. Um so in a certain sense certificate transparency gives you a kind of feed for new hosts names. So if you’re permanently observing these logs as they are public like there’s an API you could just simply request a new certificate from them um and then you can look into these certificates and see hostnames 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 and now I want to kind of switch the topic a bit to something which may appear like something completely unrelated at first and it's uh web applications and when I talk about web applications here I mean things like self hosted web applications. So things like WordPress, things like Joomla or things like Nextcloud uh these are usually written in PHP usually use MySQL you probably all know one of these, like. It’s typically content management systems and similar things. When you install one of those um -e what usually happens so you upload the files from the software to some web hosting company or on your own server um and then usually you just call the webpage and get an installer and click through a few things. It 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 protections so everyone who like if someone else calls this installer he can install it just as well. So um and this has been known for a while. Like people have been using Google to search for unistalled 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. And so but the new idea here is um there’s a small time window between when a webmaster uploads the]is application and when he finishes the installation. And if we can hit that time window we have an attack cause then we we can do the installation and uh 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 tech. So we can monitor the certificate transparency logs all the time probably with some kind of contra business script automated, and extract all the hostnames. Um and then we check these hosts like we do a Curl or a W Git on them and compare what they’re 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 you’re a real attacker we would probably do this automated of course cause eh 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 it can upload a plug and basically that gives you code execution. Um and we 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 installers work is usually just when they finish they write down a conflict file and if we delete that conflict file then the installation is undone. So um 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 um and there’s for example a service called FreeMySQL hosting dot net which offers free MySQL hosting which is very convenient for what we are trying to do. Um... yeah so we have a little demo. Um so what I’m doing here- this is the search engine I mentioned earlier. So umm and what I’m now doing is ju- like I  put in a percent which is a wildcard character and then I put in dot TIS  fun dot DE. That is one of my own domains. Um and I’ll make this a bit bigger. You see like the the very latest entry here is for block dot TIS fun dot 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 ok now we need his database credentials um and uh as I’m prepared for this I already have database credentials here. As I said from free MySQL hosting. Umm ch-- password...and this host. Ok..run on install… so now I need a side title I’ll just use test and username Admin. Wants a password from me. And an email there I’ll just use something at trash mail. And installation. Now it takes a bit. Ok. So it says Wordpress has been installed 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. Ok and um now I go in plugins and click on “add new” and here so I 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’ve prepared before which is called Hijack um and we’ll install it. Ok. So now in this plug in I have uh file called Shell PHP and it doesn't show me anything because it wants a secret. Secret is DEFCON2017 it’s not very exciting but ok. Ok and this is a very simple PHP Shell so we can make LS and we can also umm ok 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’ll get all kind of Unames so I basically have a shell now. Umm and the interesting thing is I also here have a button which says “remove installation traces” umm I’ll just try to let you see that...yeah that’s better. And now if I go on this again...then you’ll see the installer is 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 we’ll know of. Um yeah. That was the demo. [applause]
Umm so one challenge we hear that we have is that the certificates are not immediately public eh, there is a time lag which so it is a maximum two hours but eh uh I have kind of measured it and it's usually about 30 minutes. So from certificate issuance til the certificate ends up in a log. Um but uh 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 will just hit enough vulnerable hosts in that time frame. Um and uh this could also be further optimized like you could say I am not only checking a site once but when I see a new host in the certificate transparency logs I just check it every five minutes again and again for maybe a couple of hours. Umm so umm I ran a test group where I was searching for these installers with certificate transparency logs over 3 months and I could have taken over 5 thousand Wordpress installations in that time. So that’s quite a nice spot net. Ff you have 5 thousand uh b- 5 thousand ways to execute PHP code use that to send spam or host phishing sites or whatever. Um also around 500 Joomla installations, 120 Nextcloud and 70 OwnCloud. The others were all quite low so the others I would say it probably doesn't deserve the effort. Umm one thing is eh  true part doesn't show up because their installer page is uh so slow that the time out of my script hit. [crowd laughs] Um so [more laughter] Um but yeah. That’s just kind of a technicality. Um 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 its just without any protection out there in the internet and we just hope nobody finds it. Um um the challenges o-of course the 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. Um so one one thing you can imagine is 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 forum, and only then he can install the application. That’s one option but of course there are other options as well. Um so I reported this to a couple of vendors, primarily the big content management systems because they are the most interesting here. Uh so from Drupal, Typo3, and OwnCloud I got no reaction at all, they just ignored my messages. Um then from Wordpress, NextCloud, and Serendipity they uh 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 OK I’ll set up a mailing list umm but then there was not a whole lot of discussion. So um. Umm this is interesting uh MediaWiki is not vulnerable to it 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 conflict file but they provide the conflict file for download and you have to download it and then upload it again to your webhost uh otherwise the installation doesn’t get finished. Um although um uh 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. 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. Umm and then Joomla, Joomla was the only um content management system that implemented a fix after I reported it to them they released it a couple of days ago. Um and what they are doing um is that that is was uh basically my idea the problem is I don’t I later decided that I don’t like the idea any more. [crowd laughs] Um so um what they are doing is they are whitelisting localhost as a MySQL server so if you have a local database server uh the installation is just like it was before. And if you have an external MySQL server then they have an extra authentication step. And uh the extra authentication step is that uh 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. Um 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. Uh 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 the 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 with it. Um so what can you do as a user? Like if you think now “Ok, that’s um that’s a problem I don’t want my Wordpress to get hi-jacked before I even use it um how can I protect myself?” Um you can say ok. [audience laughs] Re-file yeah, as I said these logs are not updated instantly so you have like 30 minutes but eh eh 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 its running much faster and then this doesn't work anymore. So I don't think it’s a very good solution but yeah you could see about that. Um then there's a thing called cer- certificate redaction so uh with the certificate transparency some certificate authorities were worried that uh oh that means all these hostnames are now public and our customers might not like it. Um particularly Symantec now already offers that so so there is uh a part of certificate transparency where you can have redacted domain labels so you can say this certificate in the log is for redacted label dot something dot com. Um but um I don’t think that’s very practical either. So for one uh as soon as the Google crawler sees your real certificate you’re still again in the log uh and uh the other thing is umm not all certificate authorities offer this and it’s also this has been quite controversial so I-I am not entirely sure if if it’s gonna stick around. And particularly if you have some web host that automatically issues certificates for you they are likely not gonna use this. So it’s also not a very good solution. Um you could use an HTaccess file to just password protect your installation um that works um a problem is that some of these applications use HTaccess themselves to configure things um. And you need to make sure that that doesn't interfere. Like 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 uh patching software goes regressively through all the directories uh uh to scan for HTaccess files. Uh that doesn’t work in all web hosting environments because sometimes you only have Right Access in your web root, 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. Um so yeah defending as a user is hard here. And we really need fixes from vendors here. Um 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 uh with just random subdomains from my domains and checked if anyone would access them. And ok of course my own test group would access them. That’s obvious. Um and I also saw this um in the log file uh 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 like that this data of course it can be used for attacks but it can also be used for legitimate purposes like doing statistics looking for a new website. That I think is leg- legitimate use of that data. Um so so I think nobody is exploiting this yet but that might change um yeah. So um my other take away I think is um un-authenticated installs are a security risk and I really think uh these web applications need to do something about that and should fix this. Um then one thing and and I think that message many people haven’t gotten yet. There are no more secret hostnames 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 a 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 uh server name indication. Um but right uh now it’s a really broken assumption. So if you have HTTPS for your webpages you must assume that the hostnames are public. And it’s also interesting if you're maybe a pentist or looking to back bounty program this is a good way to search for host names from companies. Um and yeah final take away like uh certificate transparency is a very useful data source both for attackers and defenders um and I’d like to say something that that I find important. So I when I submitted this talk I feared a bit that people might use this as an argument against certificate transparency. And therefor I want to make very clear that I don’t think it is. Like I think certificate transparency is an amazing system it’s probably the best security improvement the TLS ecosystem has seen in a while um. And I think the problem really here lies elsewhere. Certificate transparency is just kind of amplifying the problem of un authenticated installers here. So yeah. Um yeah I think um I was I was pretty fast so we should have time for some questions. Thank you. [applause]