Sorry Tom, but I’m afraid I’m with obj in this case - just about every post you’ve done on here has been a complaint - apologies if that is not what you intended, but that is how they are coming across.
shure 
but this is not the answer to the question. i still believe that this thing is unneeded insecure - and nothing here convinced me that it is not.
that’s all
Here are a few links about security for the RPi.
instructables.com/id/Raspber … /?ALLSTEPS
thank you sjacket,
this is what helps in the thread. i’ll read that and look whether i missed things securing my pi.
We’re in the middle of evaluating PiAware (currently just for an antenna survey for 1090) in a commercial/enterprise context. We put the Pi on it’s own VLAN (DMZ) and firewalled it off (whitelist with DPI and networked-based IPS+IDS). I’m wouldn’t be so worried about the auto-update feature but I really don’t like that you can execute arbitrary commands from the FlightAware website. These accounts don’t have two-factor authentication (nor does the send command feature) so if the account tied to a PiAware unit were to be compromised it’s essentially a backdoor into the network.
If we decide to use a PiAware based receiver, our plan would be to create a new FlightAware account just for the receivers for compartmentalisation purposes, also, I’d be looking through the Debian configuration as well to see if anything needs hardening and to see if the auto-update mechanism is appropriately secure (Eg: HTTPS? packages digitally signed? etc.).
PiAware cannot execute arbitrary commands from the web site, only the handful of pre-determined mundane commands listed in the dropdown, none of which provide remote access to the device or your network. You can inspect the source to see this.
The FlightAware user accounts do support two-factor authentication, you can setup your phone at flightaware.com/account/manage/two_factor
For a commercial application, you might be better off contacting us to evaluate hardware options if you’re interested in purchasing an enterprise solution.
hello staj,
yep this is more or less what i did too - and wanted others that maybe didn’t point to this thing
i agree completely. my intention is definetly not to complain ‘how bad flightaware is’ - the opposite is true - i found this at the moment the very best application on the market.
Apologies for the misinformation, although that two-factor link doesn’t work for me, it just redirects me to the manage account page and I can’t see any link for it on that page and apologies again about the command feature, my browser didn’t render the dropdown box arrow on the right so I wrongly assumed it was a text field without actually trying to use it.
With the above being true, I don’t really see any increase in security risk beyond deploying any other device with vendor issued updates. If anything, I praise FlightAware for doing it because out-of-date software is a leading cause of successful attacks.
As for an enterprise solution, we’re in the process of doing an antenna survey to detirmine our coverage for our test site because we’re still unsure of how many receivers we’ll need and where we might need them in order to achieve MLAT for aircraft without ADS-B. Although we could have just used dump1090 on anything we just decided to put together a PiAware unit with the MLAT client for the moment with a better quality SDR and filter although we’re still waiting on some antenna work. Once we’ve got a better idea of what we need, we’ll be looking back at receivers.
dbaker, maybe i’m wrong but in my opinion of course there are no arbitrary commands possible in flightaware website - but anybody from flightaware staff - could do. but what’s much more important anybody hijacking the website could …
correct me if i’m wrong
[quote=“TomMuc”]
I’m glad you hedged with “maybe I’m wrong” – because the good news is you are. 
You can inspect the source code. It does not support anything other than what’s listed. I made this clear above and in prior threads.
It’s predefined on Pi end as well as website. fa_adept_client.tcl. The connection uses TLS and even disables the older vulnerable protocols.
ok - but as piaware runs as root i think there are other options of exploits … anyway - got my new antennas to test - so much more fun :))) http://discussions.flightaware.com/ads-b-flight-tracking-f21/antenna-testing-202-aircrafts-simultaneously-t36066.html
What are they? I’d like to fix them. Running as non-root is a good thing but if there are problems in piaware it is only a mitigation, not a fix.
i think it’s just easier to control the whole pi when already controlling an app running as root - that’s all
hmmmmm - and how about:
→ perfectly secure coded piaware from obj (and perfectly is not ironic!)
→ bad guy at flightaware (more likely bad guy who hacked fa webserver) installs via update command self-cracked piaware
???
and one more thing obj - i highly appreciate your coding - even if you say i only complain
Reduce your attack surface by turning off services you don’t use (eg: inbuilt webserver) and by utilising a host based firewall (eg: iptables) on the Pi to limit your exposure. One of the good things about a system like this is the behaviour is very predictable, if you’re using a network-based IDS/IPS you can configure them pretty easily to detect unusual behaviour and stop it from going beyond the device if it does get compromised. I’m ignoring possibly vulnerable clients that connect to dump1090 but if you’re facing the sort of threat where they would load in a malicious dump1090 in order to exploit vulnerable clients that use the data, I think you have bigger issues 8)
You could probably use a transparent HTTPS-MITM proxy between the internet and the Pi if you really wanted to but that’s in the realm of diminishing returns and is overkill.
If you are allowing updates then you are implicitly trusting the flightaware-supplied packages.
If you have disabled updates then this attack is not possible.
(FWIW this sort of attack would require quite a bit more than just compromising a frontend webserver)
Also, this really has nothing to do with running as root or not, it has to do with “does piaware have sufficient permissions to install packages”, which it must have by definition to continue to support automated upgrades. For example if you look at piaware-mutability it supports this by allowing the unprivileged piaware user to run specific commands via sudo.
Two things:
-
There is no such thing as a perfectly secure piece of code. If you want to secure your Pi with the utmost level of security, disconnect it from the network, disable the NIC, don’t have any sort of wireless capability and keep it powered off, locked in a safe. That should slow anyone who wants access to the data in it down enough to not be a worry. Other than that, every single thing to do with the Pi is a calculated risk. I’ve reviewed the source code since I was a little worried about it the same way you were, however it did check out. I already have a DMZ at home, so I just put the Pi in there since it doesn’t need internal network access anyways.
-
I find it highly unlikely that someone will hijack the PPA, create malicious code and publish an update with nobody noticing. Sure, it could be a way to assemble a pretty big botnet, but I think they’d find better luck just getting higher power systems that are using default credentials on the internet. If anything should take a swing at the piaware network, I’d imagine it would be a DDOS attack on the servers themselves, but even then, it would be purely aesthetic since the FAA doesn’t use this system for tracking flights.
- Robert
(Network Security Engineer)
ok - you guys all convinced me that there are higher risks in other parts of life. hopefully i don’t stumble over my antenna-cable doing my preferred testing now :))) thanx to all for their input - highly appreciated!