Sunday, October 26, 2008

Comcast's Incompetence Puts You at Risk

I'm moving soon and I'm trying to get Comcast setup at the new location. I went through their online ordering process, and aside from the fact that there was no useful information given to differentiate one "package" from another, the process wasn't too painful... until the last step.

At the end of the process, they require that you chat with a representative online in this shoddy Java applet. I assumed the representative would simply verify some information, then wrap things up. But actually, she said that she needed my SSN. She also reassured me numerous times that "COMCAST is all about protecting customer confidentiality", and that my "information is secured and cannot be viewed by anyone else." Hmm, I thought to myself, I do see that this applet was loaded on a page fetched using https, but how do I know that the applet itself is communicating with the server securely?

So, of course I immediately started tcpdumping the session.

$ sudo tcpdump -s0 -i en1 -A 
...


And sure enough, I started seeing unencrypted communication between the applet and the server.

(applet -> server)
21:54:36.590164 IP 10.0.1.198.60082 > 66.179.151.44.http: P 26477:27264(787) ack 37992 win 65535
E..;.N@.@...
...B..,...P...0.6..P...,e..GET /sdccommon/lachat/poll/send_msg.asp?fmt=sst&dtype=msg&Msg=... HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Mac OS X 10.5.5) Java/1.5.0_16
Host: www.comcastsupport.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Cookie: CCSSLB=XXXXXXXXXXXXXX; ASPSESSIONIDQSTACRRA=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;
dbsession=XXXXXXXXXXXXXXXXXXXXX; ASPSESSIONIDQQQAAQRA=XXXXXXXXXXXXXXXXXXXXX


(server -> applet)
21:55:54.626048 IP 66.179.151.44.http > 10.0.1.198.60082: P 54493:55606(1113) ack 39154 win 65535
E...V.@.p...B..,
....P...6......P..._...HTTP/1.1 200 OK
Date: Mon, 27 Oct 2008 04:55:55 GMT
Server: Microsoft-IIS/6.0
X-Server: sg-ec-ch05
X-Powered-By: ASP.NET
Pragma: no-cache
Content-Length: 842
Content-Type: text/xml; Charset=utf-8
Expires: Mon, 27 Oct 2008 04:54:55 GMT
Cache-control: no-cache

REQUEST_TYPE=STATUS-POLL
USER{
USER_NAME<Adela>USER_NAME
TYPING=false
SI=
RC=
CMD=
IDENT=
USER_TYPE=analyst
EMAIL_ADDR=Auto Invitation
STATUS=working
PROBLEM <Order Information>PROBLEM
ROOM=XXXXXXXXXXXXXXXXXXXXXXXXXXXX
USER}
USER{
USER_NAME<James_>USER_NAME
TYPING=false
SI=
RC=
CMD=
IDENT=
USER_TYPE=user
EMAIL_ADDR=
STATUS=working
PROBLEM<Order Information>PROBLEM
ROOM= XXXXXXXXXXXXXXXXXXXXXXXXXXXX
USER}
MSG{
ID=XXXXXXXXXXXXX
TYPE=msg
FROM<Adela>FROM
TEXT<Okay, no problem then. If you really think that this chat is not secure, you can call...>TEXT
TIME<10/27/2008 12:55:52 AM>TIME
MSG}
QUEUE{
NAME<sales6>NAME
ID=XXXXXXXXXXX
COUNT=0
AHEAD=0
QUEUE}


In the end, the chat channel clearly was not encrypted. And during the conversation they send your name, address, phone, and SSN through this chat session, and they claim that the information is secured.


I would advise everyone to NOT trust online orders with Comcast, especially ones that use the Java applet pictured here. Or perhaps the better advice is to just not trust anything with the word "Comcast" on it (except for this blog post).

I don't know why I'm still amazed by their consistent incompetence.