What Caused the Trump Website Hack?

p>Our last post, which reviewed both President Trump's and Vice President Biden's websites, was our most visited blog post ever. We intended not to broach the topic again, because let's face it – politics is toxic! But, word got out this week that the President's website was hacked, defaced, and replaced with a cryptocurrency scam, which is within the realm of topics we like to cover in this blog. Anything related to content management, in general, is prone to get our attention.

Also, this was an under-reported event. Many people didn't even know it happened. I suspect this is simply because of the news cycle being inundated with other, more "interesting" stories. However, despite this, there is a lesson here that we need to study.

Our last article pointed out that we were shocked that the Vice President is utilizing WordPress, as we felt it was one of the least secure CMS solutions out there. Little did we know that the President's site, which was built on what some may consider a safer platform, was the one to be hacked.

But why?

In this post, I want to review some possibilities of how such an infiltration could happen and lessons that can be learned from the episode.

As mentioned last week, the Trump website is powered by ExpressionEngine; a CMS built upon CodeIgniter, a popular LAMP-based MVC framework. CodeIgniter is a dependable platform, and ExpressionEngine has been around for quite some time as the standard CMS option for this framework. In many ways, we feel that ExpressionEngine is a safer, more solid choice from a security perspective. Many people have opinions on the subject, and when compared, ExpressionEngine typically rates more secure than WordPress does. But, how could someone access and hack into it? Here are some possible ways the intruder gained access.

Stolen Login Credentials

Faulty credentials are often the most likely culprit for intrusions. Sadly, it is also the most preventable cause of malicious actors taking over websites, applications, social media accounts, and even worse: banking information. Prevention is straightforward: first, create and enforce password restrictions. Secondly, install two-factor authentication to your services and CMS admin area. Finally, consider firewall protections to those administrative functions. This is the most comfortable area to secure and keep safe if proper protocols are in place.

Access to Secondary Services

The Trump campaign appears to utilize Cloudflare as a DNS service. Cloudflare is a fantastic tool that can provide many additional security, scaling, and DNS support levels. To work, it takes over your DNS settings, which controls your domains and how outside services access your site. In theory, the attacker could have gained control of this service and pointed the domain elsewhere. The same could happen if they accessed the domain registrar. Either way, however, this is unlikely because the attacker would most likely have had to get through two-factor authentication, which most of these services require. Also, a hacker would have to be more careful in this approach, as those services are experts at isolating an attacker's location and tracking them down. As such, we believe this is not a likely source of the attack, but it is indeed a possibility.

File System Access, CMS Code-based Vulnerabilities

Another area of access is the server itself. There are a few ways you can gain access to a file system. We've recently even seen where hackers take advantage of old code to install files that serve as file system browsers and take over servers. It's possible, and a lot of it would depend on if the website was built with these vulnerabilities in mind or not. Older websites tend to fall victim to these accounts – sites where the owners neglected maintenance over time or are still running old software packages. But a site that was recently developed would be less likely to feature these issues. If the site was built in the last year or so, having something like this happen is almost malpractice. This is a possible vector for the intrusion, but I hope the original developers had already done the necessary development to avoid these issues from occurring.

What Probably Happened

A week or two ago, we learned that Trump's Twitter account was accessed, as someone guessed that the password was "Maga2020!". We're not kidding. Given the fact that ExpressionEngine is somewhat secure, and the campaign was utilizing security services such as Cloudflare, it is most likely that someone with top-level CMS permissions had their credentials either figured out or stolen. Of course, we can't be 100% sure of this, but it seems the most likely culprit. Organizationally, it looks as though there were either no password policies in place or they were, in fact, fragile. This isn't a criticism as much as it is an observation. So if one had to guess how the infiltrator gained access, I'd look here first.

Any other methodology for intrusion seems much more complex and less likely. And, given the speed at which it was uncovered and corrected, it would appear that this is the way things went down. If intrusion were through more profound means, it would've been a longer diagnostic and perhaps a more extended, drawn-out downtime experience.

Key Take-Aways

So what can we learn from this episode? First, tighten up your passwords! This is a no brainer. Study this article at Wikipedia on password strength as a primer. Then, create a password policy if your organization doesn't have one and figure out how to enforce it. For CMS security, consider adding two-factor authentication to your admin login. Enforce VPN access to the admin panel, with IP restrictions for logins. Finally, conceal the admin area! We're big fans of decoupled CMS installations because they separate the admin area from the user front-end. If you can't do that, at least hide it so that no one can easily find where it is housed. This is called "Security by obscurity," wherein flying under the radar provides additional safety.

I like to always tell my clients that there are two types of intrusions. You have the automated type - typically these are looking for known exploits in a bulk fashion, ie, worms or crawlers looking for outdated code. Then, you have the types of attacks where someone is targeting you specifically. In the latter case, at the very least, remove the easiest methods so they have to work to gain access. Passwords are always the first place attackers look and often, they are successful. If you tighten up the obvious stuff, you've won half the battle.