Gov-TLS-Audit got a brand new domain today. No longer is it sharing a crummy domain with sayakenahack (which is still blocked in Malaysia!), it now has a place to call it’s own.
The domain cost me a whooping $18.00/yr on AWS, and involved a couple hours of registration and migration.
So I felt that while migrating domains, I might as well implement proper security headers as well. Security Headers are HTTP Headers that instruct the browser to deny or allow certain things, the idea being the more information the site tells the browser about itself, the less susceptible it is to attack.
I was shocked to find out that Gov-TLS-Audit had no security headers at all! I assumed AWS (specifically CloudFront) would take care of ‘some’ http headers for me — I was mistaken. Cloudfront takes care of the TLS implementation, but does not implement any security header for you, not even
strict-transport-security which is TLS related.
So unsurprisingly, a newly created cloudfront distribution, using the reference AWS implementation, fails miserably when it comes to security headers.
I guess the reason is that HTTP headers are very site-dependant. Had Cloudfront done it automatically, it might have broken a majority of sites And implementing headers is one thing, but fixing the underlying problem is another — totally bigger problem.
But what security headers to implement?
Couple months back I started GovTLSAudit. A simple service that would scan
.gov.my domains, and report on their implementation of TLS. But the service seems to have benefits above and beyond that, specifically around having a list of a government sites that we can use to cross-check against other intel sources like Shodan (which we already do daily) and VirusTotal.
So here’s 3 times GovTLSAudit helped secure government websites.
That time Yayasan Islam Terengganu was used a phishing website
I used virustotal’s search engine to see if they had extra .gov.my domains to scan, and found a few rather suspicious looking urls including:
This was an obvious phishing campaign being run out of a
.gov.my domain. Digging further, I found that the IP address the malicious urls resolve to was local, and belonged to Exabytes. And while the root page was a bare apache directory, buried deep within the sites sub-directories was a redirect that pointed to a Russian IP.
I took to twitter to report my findings — I kinda like twitter for this, and the very next day Exabytes come back with a followup that they were fixing it. That’s good, because having a phishing campaign run on
.gov.my infrastructure isn’t exactly what you’d like.
There’s a lot more details in the tweet about how I investigated this,– click here to follow the thread. A warning though — I regularly delete my old tweets. So get it while it’s there :).