FOX Broadcasting – Web Security Observations

I was recently taking a non-intrusive, public look at FOX Broadcasting’s advertising architecture after catching some interesting behavior on YouTube. My attention was eventually draw to their main page, Working in security, I make it a habit to quickly run through some security basics to see if there’s anything that stands out and could potentially turn into an exploit or, at the very least, a bad day for a web admin.

Unless I’m worried about some advanced IPS setup that will bring eyes onto my session and force me to renew my VPN connection, I’ll run an nmap scan. is hardly an HVA host, so that’s what I do.

Nmap scan report for (
Host is up (0.012s latency).
rDNS record for
Not shown: 998 filtered ports
80/tcp open http AkamaiGHost (Akamai's HTTP Acceleration/Mirror service)
| http-robots.txt: 40 disallowed entries (15 shown)
| /includes/ /misc/ /modules/ /profiles/ /scripts/
| /themes/ /CHANGELOG.txt /cron.php /INSTALL.mysql.txt
| /INSTALL.pgsql.txt /INSTALL.sqlite.txt /install.php /INSTALL.txt
|_http-server-header: AkamaiGHost
| http-title: FOX Broadcasting Company | Full Episodes, Shows, Schedule
|_Requested resource was
443/tcp open ssl/http AkamaiGHost (Akamai's HTTP Acceleration/Mirror service)
|_http-server-header: AkamaiGHost
|_http-title: Did not follow redirect to
| ssl-cert: Subject: Century Fox Film Corporation/stateOrProvinceName=California/countryName=US
| Not valid before: 2017-01-20T00:00:00
|_Not valid after: 2017-10-16T23:59:59
|_ssl-date: TLS randomness does not represent time

As we can see, is served by AkamaiGHost. There are is telling server or application information. Port 443 is open for SSL, but HSTS isn’t enabled; users, unless they specify https:// in the URL or follow a link with it, will by default land on http. This in itself isn’t a big deal since disallows user creation through their application. The only non-FOX user authentication is handled by what appears to be OAuth2, which validates TV subscriber credentials and subscription level with the cable provider.

Taking a look

We can see that robots.txt has 40 disallowed entries. Some of these look interesting, so let’s take a look.

Drupal 7.53, 2016-12-07
- Fixed drag and drop support on newer Chrome/IE 11+ versions after 7.51 update
  when jQuery is updated to 1.7-1.11.0.

We now know that runs Drupal 7.53.


Somebody left Drupal’s install.php file in the installation directory, and it’s publicly accessible. This is an issue for various reasons. To my knowledge, there are no know exploits for Drupal 7.53’s install.php file, but it wouldn’t be difficult for a motivated attacker to leverage this as an independent exploit or part of something more complicated. A specific example of something that can go wrong is an exploit found in Drupal 7.16 and earlier, described here. That’s not the first or the last exploit, and with enough time, skill and creativity, 7.53 is vulnerable. FOX should delete this ASAP. I attribute this to bad web administration and careless DevOps.


The file is available, but restricted by access permission. It wouldn’t take much time to get around this or use it as part of an attack. There’s no reason to keep have update.php accessible. I also attribute this to bad web administration and careless DevOps.

In short, XML-RPC is used for remote management. In the past, there have been critical security issues with it. Unless you require remote management, this file should be removed. If remote management is required, it should be restricted to request sources, which it isn’t:


HTTP/1.1 200 OK
Server: nginx

I have no reason to believe this login page is used by employees, but it’s possible that it is. In the event that it is, the page is entirely insecure. HSTS, as noted before, isn’t enabled. The POST request for the login page is made over http even though the application does support https.

Why it matters

Based on the above, we can conclude:

  1. is using Drupal 7.53, the latest version of Drupal 7 as of this being written. They are staying current with their software versions.
  2. Their web administration and DevOps practices leave much to be desired in terms of security. Default paths are used and no steps are taken to secure the installation.
  3. HSTS isn’t used.

These are important because:

  1. If were targeted for attack, they would be able to find and validate exploits on an entirely identical local setup. Since makes their Drupal version public and they maintain default paths (and very likely default R-W permissions), the process would be trivial at best for a skilled and motivated attacker. Finding exploits takes time, patience and skill, but it happens every day and can happen for Drupal 7.53. makes no effort to mitigate anything. To add to that, has a bunch of unnecessary and potentially risky installation files out in plain  view. Prohibiting indexing by listing it in robots.txt isn’t mitigating anything.
  2. HSTS isn’t used. TLS isn’t only used for protecting authentication requests. It provides data integrity. When you visit, you’re loading content that you inherently can’t trust. in no way provides data integrity, so you’re loading whatever is written on the page. If publishing were ever compromised, there would be no protection for users from malicious code. If Xhamster can enable HSTS, so can There is never a reason or excuse not to leverage TLS in your security strategy. If you don’t have the technical staff skilled enough to advocate for and implement is, you have a staffing issue that will eventually haunt you.
  3. According to, is ranked 5,455 globally and 1,202 in the US as of this being written; 78.8% of visitors originate from the US, 2.1% from Canada, 1.5% from UK, 1.0% from India, and 0.8% from Germany. For such a relatively high profile and trafficked website, there’s a massive absence of basic security precautions.

It’s clear to me that the issue isn’t negligence, rather a lack of security paranoia and training which is necessary to maintain security for customers and users. You’re fine until you’re not, and if you leave yourself open to attack, you’ll eventually be attacked. In security, you want to be like the State Patrol – you’re a proactive agency, and you proactively seek violations to prevent vehicle accidents. You don’t want to just wait for calls to service, because by then something has already gone wrong. You want to be strong in your prevention and response. Have preventative measures that you take seriously and implement, and have a documented and tested response for when those measures fall short.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s