Last night, a friend of mine directed me to an interesting article on Slashdot. The article publicizes Comcast’s new implementation of DNS hijacking on non-existent domains to all of their customers. Having just installed Comcast Cable a week prior to this I tried it out for myself. After going to a non-existent domain, I was immediately redirected to an ugly, ad infested page telling me that Comcast was not able to find the domain specified, and to try and respell my web address or use their search to help me find what I’m looking for.

Not only does this break internet standards, but it becomes a huge issue for IT professionals who manage the network and applications used by thousands of employees in a large company. As discussed in the comments of the article, many large companies use a split tunnel VPN to allow employees to have access to the internal mail server hosted on the company’s intranet. DNS resolution normally works by attempting to resolve a domain name primarily via the external DNS server, and if an IP is resolved, that IP will be used. If the DNS server returns NXDOMAIN, than the internal DNS server within the VPN is queried for an IP. If the internal DNS server returns an IP, than that will be used, otherwise it will return NXDOMAIN. This poses an issue to an employee using a split tunnel VPN to access the internal mail server of his/her company, because when that employees mail client attempts to resolve a domain name existent only via the VPN’s DNS server, the mail client will first query the external DNS server via their ISP. This would normally return NXDOMAIN and point the mail client to query the internal DNS server via the VPN which will return the correct IP to the mail server, but instead, anyone using a Comcast connection with their mail client would resolve an IP to Comcast’s hijacked page when the external DNS is queried for an IP, timing out the mail client.

Although Comcast does offer a way to opt-out of the service by using your modems MAC address and your customer email; it is still an obnoxious process. Although some people enjoy the help of Comcast pointing them in the right direction, many do not. Although DNS hijacking may not be new for users of the open source DNS alternative, OpenDNS, it sure is new to Comcast users.

After looking around a bit, I decided to take a more in depth look at the page that everyone is being redirected too and noticed a few serious security threats. I have contacted Comcast and made them aware of these threats.

The first thing I noticed was that the search page was vulnerable to an XSS exploit via the GET variable “url”.

http://search2.comcast.com/?cat=dnsr&con=ds&url=%3Cscript%3Ealert%28%22XSSed%22%29;%3C/script%3E

I also came across another XSS vulnerability on their SSL certified login page via the GET variable “pf_sp”.

https://login.comcast.net/login?pf_sp=%3E%22%3E%3Cscript%20%0A%0D%3Ealert%28%22XSSed%22%29%3B%3C/script%3E

I consider these XSS vulnerabilities to be quite serious considering the fact that the host is that of a trusted ISP and one of the servers is SSL certified. All it takes is a spoofed email address and some creativity to take full advantage of this vulnerability and threaten the privacy of unknowing Comcast customers.

After stumbling across this vulnerability I decided to dig a little deeper and ended up finding out a few more threats. Their Apache version is outdated, leaving their server vulnerable to moderate security threats patched in newer versions as well as the infamous Apache Mod_Rewrite Off-By-One Buffer Overflow Vulnerability allowing memory corruption on the server. I also noticed that they kept their Apache server-status enabled. Intentional or unintentional, keeping this enabled gives malicious users more information than they should have access to about your server as well as access to a real time feed of every request made to the server by what looks to be Comcast customers everywhere.

Server Information:

Server Version: Apache/2.2.3 (Red Hat)
Server Built: Jan 11 2008 08:19:18
Current Time: Friday, 07-Aug-2009 00:00:18 GMT
Restart Time: Monday, 27-Jul-2009 14:57:00 GMT
Parent Server Generation: 0
Server uptime: 10 days 9 hours 3 minutes 18 seconds
Total accesses: 7652257 - Total Traffic: 18.0 GB
CPU Usage: u48.81 s5.23 cu0 cs0 - .00603% CPU load
8.53 requests/sec - 21.1 kB/second - 2527 B/request
7 requests currently being processed, 7 idle workers

Real-time server request view

Untitled-5

Enabling the Server-Status page in Apache is great for debugging and testing, but not so great for ISP’s server handling every customers search queries and misspelled domain names.

And the last thing I stumbled across was a backup of a PHP file stored on their server resulting in source code disclosure. For legal reasons I will not post the URL to the backup file, or the Server-Status page until Comcast has fixed these issues.

I am still very happy with my Comcast cable, but a little disappointed by their lack of security, server side or not, they are an ISP and should take more precautionary matters to protect their customers form such threats.

*UPDATE: Thanks to a prompt response from Giedrius Trumpickas, a principle engineer at Comcast, I have been notified that the XSS vulnerability located at https://login.comcast.net has been fixed.