11-10-2012 06:13:20 AM
I have a couple of applications on a server behind my residential gateway, one that uses protocol 443 (https). At some point last year I found that upon invocation of my address, I was presented with a false and expired SSL certificate. After some hunting around, I found that this certificate is associated with a small web server named "mini_httpd", and further I found that it is mounted on a number of other AT&T Residential Gateways. I don't know what it is doing, I don't know how it gets installed, but I can tell you how to detect if you have it, and how to get rid of it.
Here is a link that tipped me off that a number of people with UVerse RG's have the same problem I had: http://dazzlepod.com/ip/126.96.36.199/. If that's your IP address... for that matter if you're curious whether this is on your gateway, go to a computer that is outside your network (like at work) and try to link to your IP address on port 443, like so - 188.8.131.52:443. You have to know your external IP address, but you can find it on the RG setup pages.
I believe that whoever puts this thing on the RG's is doing a brute force attack on the RG password, then doing whatever he does to install the web server. The way to get rid of it is to do a reset of all settings then a hard reboot. But you have to change the password to something harder than the default - tip, use combinations of letters, numbers, and symbols, maybe 20+ characters long. Also you need to enable an option on the firewall|advanced configuration screen that prevents excessive session attempts. I believe this will prevent it from happening again, but not exactly sure. I never changed my default password, which is only 10 numeric characters, so I figure it was breached and the virus installed.
AT&T should enable the excessive session option by default and should figure out how this thing was mounted in the first place. I am assuming that there is a lot of traffic among these things between gateways but can't be sure.
Solved! Go to Solution.
11-10-2012 09:19:39 AM
If so, the special wireless access point that AT&T provides has a web server in it to allow AT&T to manage it. That web server runs on port 443, and the RG has a permanent firewall pinhole inserted in it to divert port 443 requests to the special access point.
11-10-2012 06:46:27 PM - last edited on 11-10-2012 08:35:01 PM by Phil-101
I do.... that would be quite frustrating.
But I can't believe they would use a personal, unverified ssl certificate that is posted on a hackers web site, that expired in 2010 etc etc etc. I didn't post it above, but I found that certificate in a code repository and while I didn't look into what the code did, I'm not sure I want to know. Here it is -
[removed third party link]
I can't believe that ATT would put that same certificate in the RG. And now that I've reset/rebooted, I'm not getting the behavior anymore. But I guess that anything is possible.
11-10-2012 08:58:24 PM
Usually, self-signed certificates are used only to provide the encrypted channel, but not authentication. This is fine for AT&T's purpose since they don't need to authenticate the wireless access point, but instead just make sure that their protocol for controlling it is hidden.
11-14-2012 02:57:34 PM
Now it is back again. I cannot understand why they would put it on port 443. Take a look at this certificate, AT&T isn't that bad is it? The specific cisco application appears to have a special pinhole in the ~3300 port neighborhood, which would be more logical to me. Attached below is a summary of the certificate (same stuff I sent earlier from that hacker web site).
11-14-2012 05:09:27 PM
If you're running a web server behind the RG that uses https (port 443), you will not be able to do it with just a firewall rule. If you delete the AT&T-created rule for the wireless access point and put your own rule for your web server in for port 443, your rule will eventually get deleted and the 443 rule for the WAP will get put back in.
If you want to keep wireless STBs and run a web server behind the RG on 443, then you will have to get static IPs and run the web server on one of them.
11-16-2012 03:07:45 PM
I would assume that if I got rid of the wireless STB and had that TV hardwired, that this would go away, no? Further, since my earlier posts, I've found that the wireless transmitter that connects to the STB is the one that maintains that port, so sorry for the questions ealier!
11-16-2012 04:46:18 PM