It was Jan last year that I suggested HTTPS adoption had passed the "tipping point", that is, it had passed the moment of critical mass and as I said at the time, "will very shortly become the norm". Since that time, the percentage of web pages loaded over a secure connection has rocketed from 52% to 71% whilst the proportion of the world's top 1 million websites redirecting people to HTTPS has gone from 20% to about half (projected). The rapid adoption has been driven by a combination of ever more visible browser warnings (it was Chrome and Firefox's changes which prompted the aforementioned tipping point post), more easily accessible certificates via both Let's Encrypt and Cloudflare and a growing awareness of the risks that unencrypted traffic presents. Even the government has been pushing to drive adoption of HTTPS for all sites, for example in this post by the National Cyber Security Centre in the UK:
all websites should use HTTPS, even if they don't include private content, sign-in pages, or credit card details
However, there remains an undercurrent of dissent; Scott Helme recently wrote about this and dispelled many of the myths people have for not securing their traffic. I shared some thoughts on what I suspect the real objection is in the tweet thread beginning with this one just a few days ago:
I'm forming a theory on those who are decrying the broad adoption of HTTPS: I suspect they're pushing back because they feel like they've lost control; they're being "forced" to move due to impending changes in Chrome in particular
— Troy Hunt (@troyhunt) July 8, 2018
In one of many robust internet debates (as is prone to happen on Twitter), the discussion turned to the value proposition of HTTPS on a static website. Is it needed? Does it do any good? What's it actually protecting? I'd been looking for an opportunity to put together some material on precisely this topic so when a discussion eventually led to just such an offer, it seemed like the perfect time to write this post:
Actually, that’s perfect, I was looking for someone willing to have a static site they think is immune from transport layer risks used in a video on this. Thanks!
— Troy Hunt (@troyhunt) July 5, 2018
And just to be extra, extra sure this was Jacob's intention, he did later extend the same offer to another party and also (quite rightly in my opinion) observed that permission really isn't necessary to man in the middle your own traffic! So that's precisely what I've done - intercepted my own traffic passed over an insecure connection and put together a string of demos in a 24-minute video explaining why HTTPS is necessary on a static website. Here's the video and there's references and code samples for all the demos used immediately after that:
HTTPS Is Easy
The HTTPS Is Easy video series is 4 short videos of about 5 minutes each that make it dead simple to serve almost any site over a secure connection. Not only is the video series awesome (IMHO), the awesome community of people who've watched this have translated closed captions into 16 different languages already making HTTPS more accessible to more people than ever!
WiFi Pineapple
The Wifi Pineapple is a super-easy little device made by Hak5 that's not only easy stand up as a wireless hotspot, but can trick devices into thinking it's a known network that they automatically connect to without any user interaction whatsoever. I've done a heap of writing on this little device and regularly use it at conferences and training events.
ClippyJS
Everybody loves a bit of Clippy, just so long as it's in jest! I did this demo with ClippyJS and if you really want to relive the memories of days gone by, you can also embed Merlin, Rover and Links then orchestrate their behaviour via a set of actions invoked in the JS.
Cornify
Who doesn't love unicorns, right?! Cornify will help you liven up those otherwise dull pages with magical beasts and rainbows. Comes complete with Cornify buttons to add to your website (or someone else's).
Harlem Shake
There's actually a bit more to this than just entertainment value, the Harlem Shake has regularly been used as a "proof" for running script on a vulnerable site. For example, check out how it's used when embedded in the TXT record of a DNS entry which is then loaded into a WHOIS service which doesn't properly output encode the results. There's also Brenno de Winter's excellent example of XSS flaws in Dutch banks, again, demonstrated via a lot of shaking. Grab the entire script and then inject as required.
Cryptominer
I used Coinhive which offers to "Monetise Your Business With Your Users' CPU Power". Frankly, it's a pretty shady service regularly abused for malicious purposes but that was precisely what was required in this situation.
Router CSRF Exploit
This is from CVE-2018-12529 and the sample exploit was taken from the SecurityResearch101 blog. We've often seen CSRF attacks against routers result in DNS hijacking which, of course, is yet another risk that HTTPS protects against. We've known about this for years, including how the proceeds of this crime have been used to pay for Brazilian prostitutes.
DNS Hijacking
This was done with just a few lines of FiddlerScript in the OnBeforeRequest event:
if (oSession.HostnameIs("btlr.com")){
oSession.hostname = "scripting.com";
}Were you using a device such as the Wifi Pineapple you can could achieve the same result using DNSspoof. The outcome is identical - traffic going to one insecure address results in traffic from a totally different address being returned.
China's Great Cannon
This was the attack back in 2015 that sought to take down GitHub, or at least the repository greatfire.org maintains there. I showed the de-obfuscated version in the video which you can find on Pastebin. The original version and a more detailed technical writeup on the incident can be found in this piece from Netresec. Incidentally, Baidu still doesn't serve their homepage over HTTPS by default (although the can serve a valid cert if explicitly requested over HTTPS) which gives the service the unenviable title of being the world's largest website not to do so according to Alexa.
BeEF
This, to me, was the most impactful demo not just because it resulted in pushing malware and phishing attacks to the target website, but because it shows just how much control an attacker can take over the browsing experience of victims on that site. Check out the BeEF project website for more background on that and if you want to implement the demo I ran, go and grab Kali Linux from VMDepot (now rolled into the Azure Marketplace) and deploy it directly into an Azure VM (I used the smallest size and it worked fine). I allowed inbound requests on port 80 as well as port 22 so I could SSH in. I then changed the port from 3000 to 80 in the config.yaml file (refer to the BeEF config documentation), included a script file from [vm ip]/hook.js in the victim site an browsed over to [vm ip]/ui/panel and logged in with "beef" and "beef". That's it!
Rick Roll
This one needs no introduction, going on half a billion views on YouTube, it's the surprise gift that keeps on giving!