Make your site more secure than Rudy Giuliani’s security firm

Shortly after it was announced that Rudy Giuliani would advise the Trump administration on cybersecurity, his own security firms website became under scrutiny. While it’s pretty obvious that Rudy himself doesn’t operate the site and that insecurities on the website does not necessarily correlate to his ability or inability to advise on policy, it was fun for a lot of the industry to pick on.

Let’s take a look at those easily identifiable vulnerabilities and see how you can avoid them and have a more secure site / app than the cybersecurity advisor to the President elect.


SSL
Let’s just lump the various SSL related items into one section.

Report on Jan 12, 2017

Don’t have HTTPS enabled for your site? One myth is that it’s complicated and expensive. It’s a lot better now that the world has Let’s Encrypt.

Have HTTPS enabled already? Use it by default. You can test this by going to http://yourapp.example.com (obviously use your own url) and see if it redirects to https://yourapp.example.com

Once you have SSL enabled, you will want to make sure it’s configured properly. You can scan your site and get guidance for what to do to improve your score from a few different sites.


Exposed CMS login

Your application or site may not be a CMS but it might have an admin or management interface. Because these interfaces usually have elevated privilege levels to control content or settings they should not be available from the Internet. This goes for other service management interfaces as well.


Uses Flash
It’s pretty much old news that flash has a history of being horribly insecure and that you shouldn’t be using it for anything anymore. If you do have flash as a component it’s time to sit down and have a talk about what purpose it serves and decide if the risk is acceptable.


Using EOL PHP version / other old software
Out of date software commonly contains bugs and known vulnerabilities. Keeping your software components up to date is one of the simplest things you can do to improve your security posture.


Default content / configs / etc
Viss (Dan Tentler) was the first person I saw comment on the firms site. He pointed out a bunch of files that probably shouldn’t be accessible.

While you can use tools (dirbuster, dirb, etc) to find and discover content it’s probably easier to do as a manual exercise since you have access an attacker might not. It’s important to curate the content and files that are available on your site removing old legacy content, configs, git repos, etc and making sure that your access control is setup properly. This is quite different for various setups so you’ll have to do some digging to see what works for you.


Now it might seem that these flaws are fairly trivial and many are commonplace knowledge but guess what, we still find similar flaws on security assessments that we do. Sometimes having a good security posture is just putting into action the things you already know and sometimes you need some outside help to know where you are vulnerable.


As I finish writing this it appears that the website’s DNS record for a brief period of time had been changed to point to 127.0.0.1 (localhost). So remember that if somebody gets control of your DNS server or into your registrar account, they can control where your site goes. Good passwords, 2FA and locking domains so they can’t be transferred are probably good ideas.👍