A few weeks ago an an article was posted to The Register about a flaw in BT Home Hub 5A seemingly “hunting” for a SIP server and then port forwarding on the WAN to this server allowing fraudulent calls.
Initially I called “bullsh*t” on this.. How could the Home Hub do this.. Plus The Register didn’t seem to have done the due diligence that I think they should have and actually tested and verified the flaw themselves.
tl;dr: This is a real flaw but only if you use ANY SIP software that uses port 5060 as the source port when sending register requests and have an external SIP trunk. You are unaffected if you have, for example, an ISDN30 card in your asterisk system and everything stays internal.
So I setup a test environment. (I didn’t fancy just chucking the Home Hub on my normal Infinity connection, I have way too much stuff setup to disrupt.)
Starting on the right and then going to the left:
Dell Laptop running MikroTik RouterOS in a Virtual Machine and Wireshark. RouterOS acting as a PPPoE server on the LAN port and NAT on the WiFi.
BT Home Hub 5B.. Red “WAN/Infinity” port connected to the Dell Laptop via ethernet.
Macbook Air running Windows connected to the BT Home Hub 5B over WiFi and running various SIP servers.
My main desktop computer on the left on the “WAN” side of the test setup runing a SIP client and wireshark.
First challenge was to setup RouterOS as a PPPoE server to trick the BT Home Hub 5B into thinking that it was connecting over a normal Infinity connection to BT and the internet. This took some time as it seems the BT Home Hub rejects WAN IP addresses assigned to it within 10.x.x.x, 172.16.x.x etc.. in the end we worked out it would connect if we assigned a “public” IP to it of, in our test, 81.81.81.81:
BT Home Hub connected via my fake PPPoE server:
This now means that the BT Home Hub thinks it is connected to the internet and my office PC is a random computer out on the internet:
Firstly in the default firewall mode you can’t get ICMP responses from the WAN IP of the BT Home Hub.. SIP traffic is also blocked. This is the standard setting that BT Home Hubs are shipped with.
My SIP server was FreePBX (as reported by TheRegister) and it was set with one extension and one SIP trunk registering to a provider “out on the internet” (With NO ports forwarded!).
However… flip the setting to “Block All” and suddenly the phone on the WAN can connect to the SIP server on the other side of the BT Home Hub! Later on in my testing I discover that even in factory default “Default” firewall mode SIP traffic is often forwarded still.
It is important to note that I have not setup any port forwarding or changed any default settings in any way other than to change the firewall, as in The Register article, to Block All mode. Suddenly port 5060 is open!
I have tried to track down any potential UPnP mappings on the router – none have been made. I confirmed UPnP was working by firing up BitTorrent Sync which automatically created the UPnP Forwards.
So no way to tell why or how the Home Hub is forwarding SIP traffic either in the Port Forward interface or by querying the UPnP layer. Faulty SIP helper maybe?
I presume the act of an outbound SIP connection to register with the provider kicks the Home Hub into then allowing unrestricted inbound data.
My initial testing seems to show that this problem _doesn’t_ exist when 3CX is in use or microSIP. This seems to be because microSIP and (untested) 3CX use a random source port where as FreePBX and Asterisk use SRC and Destination port of 5060.
I discuss this more in my post about Exploiting the BT Home Hub SIP ALG Flaw.
The port forward seems to be removed after ~180 seconds of no outbound SIP registry traffic.
Additional:
Looks like the Home Hub 3 may have suffered similar issues.
thecomputerperson 
Pingback: Exploiting the BT Home Hub 5 SIP ALG Flaw | thecomputerperson
I recently switched broadband to BT for my home office and had concerns configuring SIP as it did not appear I could disable SIP ALG on HH5. I use a SIP TAPI from http://www.ipcom.at to dial directly from Outlook 2013. I configured my Seimens gigaset phone to use port 5065 as an alternative to disabling SIP ALG which is not possible in homehub5. The VDSL line goes straight into the HH5 with 4 gigabit connections to laptops and server and one to the SIP box. It all seems to be working, Do I have a significant security flaw please, and is it better not to port forward? I have tested both ways and it does not seem that using 5065 is required. I currently have provider proxy and registrar ports blank, STUN not enabled, and outbound proxy on auto.. The system works both inbound and outbound, though I do not hear any ring tone during connection – only once the other party or answerphone answers.
Thanks!
No port forwards should be required in my experience (unless you have a bad device or a configuration problem).
As for not hearing a ring tone – this seems more like a configuration at the SIP provider.. the SIP provider may not be sending you a PROGRESS or RINGING(?) status so your device doesn’t make the ringing tone to make you aware that the call is progressing. Did this previously used to work on your last internet provider?
In the above example if you keep default firewall settings but disable the SIP alg (under “advanced” settings, then you get the same problem. I used the real internet for my experiment…. also with the plus.net hub one you get the same issues in a different colour box.
With a Hub 5 or a Smart Hub (Hub 6)? The Smart Hub seems like it has possibly been entirely re-written and might not suffer from the flaw.