Topic: Acurite Internet Bridge - hackable embedded Linux?

[ITbyCrayon.com]

I've been struggling with getting my Personal 5-in-1 weather station w/Internet bridge going.  I don't have much weather experience, but have done a fair amount with computer security.

When I placed the Internet bridge behind my firewall, I struggled to get to link to the ACU-link web site.  So, I moved it to in front of my firewall, but still behind my DSL router. 

After a while I still saw odd behavior.  So, I turned on a packet sniffer to debug.  I'm seeing traffic (not port 80) out to China, Japan, & Georgetown University.  (using nslookup & whois to track these down). 

Wondering if anyone else has noticed such behavior.  Wondering what normal behavior should be (I'm seeing the router on registered boot-up sometimes going to aculink and then it appears that firmware is being downloaded … makes me wonder if the firmware is corrupted). 

Hoping to speak to their tech support this week.

Thanks,

Jim

[nincehelser]

Nope.  I've done a lot of work on the AcuLink Bridge over the past year.  I've never seen it do anything like that.

The general consensus is that it isn't running Linux.  I really don't think there's much there to hack.

I once did some basic intrusion testing on it.  I couldn't find any holes.  I wish I could, because it's got issues that could use fixing.

[nincehelser]

As for your problem, see if you can figure out what IP address your bridge was assigned, then try to open that address with a web browser.

You should get the bridge's internal web page.  It might yield some clues.  If you can't get it, that may be a clue itself that the bridge is defective.

[ITbyCrayon.com]

The thing that bothers me is when I see things like this:

22:32:49.830282 IP (tos 0x0, ttl 100, id 23, offset 0, flags [none], proto: TCP (6), length: 40) 10.1.1.99.59468 > softbank126007200042.bbtec.net.16979: R, cksum 0xe99c (correct), 1246103534:1246103534(0) ack 4294967293 win 200
22:32:49.830801 IP (tos 0x0, ttl 100, id 24, offset 0, flags [none], proto: TCP (6), length: 40) 10.1.1.99.59468 > softbank126007200042.bbtec.net.16979: R, cksum 0xecf4 (correct), 1085410858:1085410858(0) ack 4294967293 w

um… softbank* ?

[nincehelser]

That's not terribly meaningful out of context but Softbank is a telecommunications firm.

[ITbyCrayon.com]

I was assuming on these units that: 
#1) Data would be uploaded to www.acu-link.com:80
#2) Occasionally, there would traffic back to the bridge on port 80
#3) Weather underground scrapes temps from acu-link, not from the sensor.
#4) Rain-guage data would be uploaded as well.

For those who have these units, is that not the case?

Why would there be non-port 80 traffic?

[nincehelser]

I was assuming on these units that: 
#1) Data would be uploaded to www.acu-link.com:80
#2) Occasionally, there would traffic back to the bridge on port 80
#3) Weather underground scrapes temps from acu-link, not from the sensor.
#4) Rain-guage data would be uploaded as well.

For those who have these units, is that not the case?

Why would there be non-port 80 traffic?

1) Yes
2) A success message is returned for each submission, but usually the bridge doesn't care.  I'm not sure if it will continue indefinitely without seeing an occasional success message or not.  That's something I'll have to test someday.
3) Wunderground doesn't "scrape" the data from Acu-Link.  The pertinent weather data is summarized by Acu-Link and submitted to wunderground every 15 minutes.  The bridge is not involved in that transaction.
4) Rain data is always uploaded every 36 seconds.

Non-port 80 traffic?  DHCP and DNS come to mind.  There's also other traffic not related to ports, such as ARP requests.

[vreihen]

Are you 100% certain that IP address 10.1.1.99 is assigned to the Acu-Link bridge, and is not a NAT address for an infected PC?  If you connect to 10.1.1.99 with a web browser, do you get the bridge's mini web server?  Could two devices be sharing the same IP address, explaining your connectivity problems as well?????

[nincehelser]

I'm confused about the whole firmware issue.  Are you letting the new firmware download?

That's what's supposed to happen if the firmware is out-of-date, and is typical on a first installation.

That's covered in the instructions: http://www.acurite.com/media/manuals/09150-QSG.pdf

[ITbyCrayon.com]

Folks,

Just to provide an update:

1. I've specifically tied the IP to the MAC addr in my DHCP server, so I know that the bridge is at the IP addr that I posted.  (and I do get the bridge's mini web site when I hit the IP). 
2. I moved the bridge behind my internal firewall, so now it doesn't post successfully to MyBackyard Weather (www.acu-link.com).  Which was why I originally moved it in front, so that it would post to MyBackyardWeather.
3. I do see non-port 80 traffic (i.e. not destined for port 80, nor coming from port 80).
4. With the unit behind my firewall and restricting non-web/non-DNS egress traffic, turning on the packet sniffer, I see the DNS request for www.acu-link.com.  Then see traffic to acu-link.com:80 with a 400 BAD REQUEST.  I haven't attempted a new registration this eve.  That'll be tomorrow.  I also see outbound port 80 to tcp 0.0.0.0 port 0, outbound port 0 to tcp 0.0.0.0 port 0.
5. My suspicion in this original thread is either the firmware was hacked from the acu-link website for download, or this device was compromised.  [Obviously, the other possibility would be that my firewall were hacked and outbound packets were going out spoofed IPs … but , I would suspect that I would see duplicate IPs on my network for my other devices which have consoles & logs].

[nincehelser]

I really don't understand why you think the bridge is compromised.

I suppose anything is possible, but it seems unlikely that someone would have directed a hack to this specific microcontroller and that you would have given them time and access to do so.

So far everything you describe is normal operation for the bridge.

Frankly, it's far more likely that your DSL modem or router is infected with a botnet like Chuck Norris.

Are you really running a Class A network?  I'm asking since a Class A networks tend to be large with lots of potential security problems.

[vreihen]

Are you really running a Class A network?  I'm asking since a Class A networks tend to be large with lots of potential security problems.

10.0.0.0/8 is used for private (non-routed) networks per RFC-1918, just like the more familiar 192.168.0.0/16.  Some cellular networks use it on their over-the-air networks, and NAT at their wired borders.  Seeing 10.x.y.z is common behind corporate firewalls, and it is segmented using CIDR to slice up the big block into smaller subnets.....

[nincehelser]

Yeah...I know what it is.  Network architecture and security are a couple of my specialties. 

I'm just trying to get a feel if he's on a large network that someone might be messing with him.

[ITbyCrayon.com]

I'm on a small network - I don't have to use class A space, but I use the space with /24.

I'm just curious why I see the following in my tcpdump output -- odd destination port of 16979.  If there are going to be more of these, is there a known port list, so I don't have to tighten firewall rules.  And the bbtec.net site is the only one that has shown with a resolvable DNS entry.  I think my first oddball traffic was out to 60.3.x.y   The tcpdump below was generated immediately following powering the unit back on.

19:51:08.833159 IP 10.1.1.99.http > 140.161.6.23.34997: R 688090938:688090938(0) ack 4259734222 win 201
19:51:08.833709 IP 10.1.1.99.http > 140.161.6.23.34997: R 1356324984:1356324984(0) ack 1 win 201
19:52:08.837278 IP 10.1.1.99.51276 > softbank126007200042.bbtec.net.16979: R 2099334304:2099334304(0) ack 2131704507 win 200
19:52:08.837817 IP 10.1.1.99.51276 > softbank126007200042.bbtec.net.16979: R 42346286:42346286(0) ack 1 win 200
19:53:08.841706 IP 10.1.1.99.51276 > softbank126007200042.bbtec.net.16979: R 0:0(0) ack 1 win 200
19:53:08.842222 IP 10.1.1.99.51276 > softbank126007200042.bbtec.net.16979: R 2526161034:2526161034(0) ack 1 win 200

[nincehelser]

I haven't analyzed exactly what's going on during a firmware download.

Given that Acurite is using "cloud services", it's a bit hard to predict what might be going on with any certainty.  The process just isn't documented for the average Joe user to look at.

I think what you should do is let the firmware update as per the installation instructions and get the thing working.  If it doesn't work as advertised, send it back.  You're just going to be chasing phantoms at this stage in the game because you don't know how that firmware download is supposed to proceed.

As far as your firewall goes, you really shouldn't need to do anything.  If you're running a policy where you have to approve everything before it goes out, you might as well give up now.  That is rarely practical, especially today.  When you put something on your internal network, you're basically going to have to trust it.  If you don't trust it, don't connect it. 

Seriously, the chances that you got a hacked bridge are extremely remote.  Like I mentioned before, I ran some of the common penetration tools against the bridge looking for a way in with no luck.  The only thing open to the outside world was port 80, and you shouldn't be letting anything outside initiate a connection to it on port 80 anyway, so just how do you think it got infected in the first place?

[ITbyCrayon.com]

Since I don't what this device is, I don't know what to expect.  I know that I did have it outside my firewall, but inside my network for a while trying to get things fully functional.

I think you are right in that I'm chasing ghosts. 

In looking at this, you'll notice a destination IP as 65.126.65.126 … turns out that the soft bank addr is 126.65.126.65.  I've seen other patterns of outbound to x.y.x.y

21:47:45.678525 IP 10.1.1.99.boinc-client > 174.143.139.166.http: R 389945350:389945350(0) ack 294 win 201
21:47:45.679039 IP 10.1.1.99.boinc-client > 174.143.139.166.http: R 4292626412:4292626412(0) ack 294 win 201
21:48:45.682965 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 3839060711:3839060711(0) ack 1 win 200
21:48:45.683481 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 4126107411:4126107411(0) ack 1 win 200
21:49:45.687288 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 3839060711:3839060711(0) ack 1 win 200
21:49:45.687803 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 3860527119:3860527119(0) ack 1 win 200
21:50:45.690943 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 3839060711:3839060711(0) ack 1 win 200
21:51:30.661969 IP 10.1.1.99.http > softbank126065126065.bbtec.net.16766: R 65416974:65416974(0) ack 1 win 201
21:51:30.662480 IP 10.1.1.99.http > softbank126065126065.bbtec.net.16766: R 3520977958:3520977958(0) ack 1 win 201
21:52:30.666437 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 4072033438:4072033438(0) ack 1 win 200
21:52:30.666957 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 440683956:440683956(0) ack 1 win 200
21:53:30.670011 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 4072033438:4072033438(0) ack 1 win 200
21:53:30.670525 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 207636192:207636192(0) ack 1 win 200


This was the last 4 packets that I had in another window at increased detail. 

listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
21:52:30.666437 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 767843863:767843863(0) ack 2118221377 win 200
   0x0000:  4500 0028 0007 0000 6406 c869 0a01 0163  E..(....d..i...c
   0x0010:  417e 417e 7e41 7e41 2dc4 5e17 7e41 7e41  A~A~~A~A-.^.~A~A
   0x0020:  5014 00c8 9bc7 0000 0000 0000 0000       P.............
21:52:30.666957 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 663617814:663617814(0) ack 1 win 200
   0x0000:  4500 0028 0008 0000 6406 c868 0a01 0163  E..(....d..h...c
   0x0010:  417e 417e 7e41 7e41 5552 5f2d 7e41 7e41  A~A~~A~AUR_-~A~A
   0x0020:  5014 00c8 7323 0000 0000 0000 0000       P...s#........
21:53:30.670011 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 0:0(0) ack 1 win 200
   0x0000:  4500 0028 0009 0000 6406 c867 0a01 0163  E..(....d..g...c
   0x0010:  417e 417e 7e41 7e41 2dc4 5e17 7e41 7e41  A~A~~A~A-.^.~A~A
   0x0020:  5014 00c8 9bc7 0000 0000 0000 0000       P.............
21:53:30.670525 IP 10.1.1.99.32321 > 65.126.65.126.32321: R 430570050:430570050(0) ack 1 win 200
   0x0000:  4500 0028 000a 0000 6406 c866 0a01 0163  E..(....d..f...c
   0x0010:  417e 417e 7e41 7e41 476e 5859 7e41 7e41  A~A~~A~AGnXY~A~A
   0x0020:  5014 00c8 87db 0000 0000 0000 0000       P.............

I ran an NMAP scan against the device tonight.  It appeared only to be listening on 80. 

Thx.

[ITbyCrayon.com]

Finally got my replacement bridge.  All seems better.  No random packets outbound & all sensors reporting.