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, FOX.com. 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. FOX.com is hardly an HVA host, so that’s what I do.
Nmap scan report for fox.com (22.214.171.124)
Host is up (0.012s latency).
rDNS record for 126.96.36.199: a23-74-70-115.deploy.static.akamaitechnologies.com
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
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-title: FOX Broadcasting Company | Full Episodes, Shows, Schedule
|_Requested resource was http://www.fox.com/
443/tcp open ssl/http AkamaiGHost (Akamai's HTTP Acceleration/Mirror service)
|_http-title: Did not follow redirect to http://fox.com/
| ssl-cert: Subject: commonName=secure.fox.com/organizationName=Twentieth 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, FOX.com 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 FOX.com 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 FOX.com 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:
POST http://www.fox.com/xmlrpc.php HTTP/1.1
HTTP/1.1 200 OK
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:
- FOX.com is using Drupal 7.53, the latest version of Drupal 7 as of this being written. They are staying current with their software versions.
- 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.
- HSTS isn’t used.
These are important because:
- If FOX.com were targeted for attack, they would be able to find and validate exploits on an entirely identical local setup. Since FOX.com 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. FOX.com makes no effort to mitigate anything. To add to that, FOX.com 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.
- HSTS isn’t used. TLS isn’t only used for protecting authentication requests. It provides data integrity. When you visit FOX.com, you’re loading content that you inherently can’t trust. FOX.com 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 FOX.com. 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.
- According to Alexa.com, FOX.com 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.