Obihai is deleting unwanted topics
RonR:
Quote from: Mango on May 12, 2012, 08:29:35 am
What RonR says is partly true. Keep in mind that in order for Obihai to regain control, the user of the device would need to dial **5xxxx. Based on what I've seen here, the function of **5xxxx appears to be to turn on OBiTALK Provisioning and OBiTALK Service, and add the device to OBiTALK.
So yes, if you turn on OBiTALK Provisioning and OBiTALK service, then OBiTALK Provisioning and OBiTALK service will be turned on.
This is NOT the case. Dialing **5nnnn does NOT turn on OBiTALK Provisioning nor the OBiTALK Service. I tried numerous variations and tests, with and without rebooting, etc. **5nnnn always reports that nnnn was sent to the provider but no change occurs to the OBi at that point. It's only when the OBiTALK Web Portal receives the expected nnnn that the OBiTALK Web Portal sends the necessary commands to the OBi that OBiTALK Provisioning and the OBiTALK Service are re-enabled and the OBi is again under Obihai control.
It's very clear that setting:
System Management -> Auto Provisioning -> Auto Firmware Update -> Method : Disabled
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
Voice Services -> OBiTALK Service -> Enable : (unchecked)
does NOT prevent Obihai from taking control of an OBi.
shap:
I think your test was incorrect - by dialing **5nnnn you will trigger communication from Obi to Web Portal, and by the end of this communication ObiTalk service will be enabled on your device.
That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.
The only way to be 100% sure that Obi can not get access to the devices - is to sniffer the traffic...
However, I do not thing it is worth to do.
P.S. I have ObiTalk service disabled and did not get firmware upgrade.
Mango:
Quote from: shap on May 12, 2012, 11:23:03 am
That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.
Bingo. With no NAT hole open in your router and no communication initiated by the device, no one from outside could possibly gain access to your device. This is basic networking 101.
FTR, I've been running Wireshark to monitor my OBi110 for the past two days and so far can confirm that Sherman's statements are correct.
RonR:
Quote from: Mango on May 12, 2012, 12:31:37 pm
I've been running Wireshark to monitor my OBi110 for the past two days and so far can confirm that Sherman's statements are correct.
With everything disabled and without being logged into any OBiTALK account, dial **5 + any4digitnumber and watch Wireshark. You'll see your OBi's product information (SerialNumber/OBiNumber/etc.) being sent off to Obihai. I guess in addition to the disabling Auto Provisioning and the OBiTALK Service, there needs to be a warning to never dial **5 as there's no way to disable it (as far as I'm aware).
VaHam:
Quote from: shap on May 12, 2012, 11:23:03 am
I think your test was incorrect - by dialing **5nnnn you will trigger communication from Obi to Web Portal, and by the end of this communication ObiTalk service will be enabled on your device.
That does not mean that Web Portal (or other service) would be able to do this without you doing ***5 first.
The only way to be 100% sure that Obi can not get access to the devices - is to sniffer the traffic...
However, I do not thing it is worth to do.
P.S. I have ObiTalk service disabled and did not get firmware upgrade.
Note: RonR says that no changes take place until after a successful connection to the OBi servers using the correct 4 digit authentication code. You don't need to sniff with wireshark or even block the OBi's ip at the border router to test this. Simply make up a four digit code which will be incorrect (i.e. **51234). The Obi will announce in voice that the code has been sent to the server however since the code is incorrect no changing of the bits takes place. What this tells you is, that it is the sequence of commands being returned to the OBi which in fact modifies these bits and regains control of the device. The control bits are not being changed autonomously by the **5nnnn command executed in the device itself without successfully connecting to the OBi server. Thus it is the server and not the device command which changes the control bits.
What that means is there must be some sequence of commands being returned by the OBi server which actually turns on or allows the Auto Provisioning and Firmware Update control bits to be changed.
If that is the case, then if OBiHai can do it then it may also be possible that the same commands could be hacked and used by someone else to do the same thing.
While the OBi can happily work behind a firewall, a firewall should not be required in order to assure protection of the device. What about remote users who have the OBi connected directly to a modem?
I am also still puzzled by the statement that OBiTALK does not use these control bits; why are they then being changed by OBiTALK?
Navigation
[0] Message Index
[#] Next page
[*] Previous page