Virus problem with KiwiSDR [fixed in v1.244]
This morning we've had several simultaneous reports of different virus scanning software giving errors when browsers attempt to access Kiwi sites.
One reporter was using AVG Internet Security (a general system-wide scanner for Windows) and the Chrome browser. Further scanning didn't reveal any problems and AVG is no longer reporting any errors.
Another reporter uses the Avast Online Security browser extension. We have tried the version 18.3.57 extension for both Firefox and Chrome but have not been able to replicate the problem.
Both scanners reported the error as "HTML:Script-inf" errors which we don't quite understand yet. If anyone can give us a solid technical description of what exactly this error means we'd be most appreciative. We're wondering if this is related to the recently added dynamic loading of Javascript files for the extensions to reduce page load time.
It is possible this was a false positive and an exception has been entered into a database somewhere. But that would seem like a suspiciously fast reaction time. So we'd be interested if others are still receiving this error.
One reporter was using AVG Internet Security (a general system-wide scanner for Windows) and the Chrome browser. Further scanning didn't reveal any problems and AVG is no longer reporting any errors.
Another reporter uses the Avast Online Security browser extension. We have tried the version 18.3.57 extension for both Firefox and Chrome but have not been able to replicate the problem.
Both scanners reported the error as "HTML:Script-inf" errors which we don't quite understand yet. If anyone can give us a solid technical description of what exactly this error means we'd be most appreciative. We're wondering if this is related to the recently added dynamic loading of Javascript files for the extensions to reduce page load time.
It is possible this was a false positive and an exception has been entered into a database somewhere. But that would seem like a suspiciously fast reaction time. So we'd be interested if others are still receiving this error.
Comments
Any clarification anyone has about this would be most welcome. We continue to be unable to replicate this behavior.
Often these reports are checksums so maybe one radio throws a bad number that has been filtered out once the AV company does a more thorough test.
If the content of the local Kiwi page header has some questionable link then maybe is detected, if that radio is the first link on the sdr.hu site it gets flagged.
I suppose you could run a URL check on the most popular radios (or those with wierd icons in the names), takes seconds and might find someone linking to an external resource that is not trusted.
However on the same day, by sheer coincidence, an actual Linux virus was found running on the Beagle of one Kiwi. This lead to the recent v1.244 release which removes the virus and sends an anonymous report to kiwisdr.com. When more Kiwis have upgraded to v1.244 we will disclose the details. So far only a few Kiwis have been found to have the virus.
I don't allow my Chinese CCTV any web access for same reason. I bought a cheap 8ch 1080 NVR and somehow forgot the password I set up while testing at work (hangs head), long story short support told the only way to recover was connect it to the net and they would reset it from China, yeah no thanks I'll go with the old type we can reset ourselves. I just put that one on the shelf as I know the exploits will be out soon enough..
The virus is the program /usr/bin/.koworker which is started by an entry added to the system crontab. This program is a robot that scans hosts on the Internet looking for open ssh ports then tries to brute-force guess account passwords. It was extremely easy to find and is completely generic, i.e. doesn't appear to be specifically crafted for the Kiwi. All viruses were installed between March and August with one going back to last November.
The real question is how did this virus manage to install itself on the Kiwi's Debian Linux disto? There are many possibilities:
- Weakness in the Kiwi network protocol allowing Linux root access.
- Weakness in the older Debian 8 distro used by the Kiwi allowing root access.
- Exploit of the Kiwi root account null-password by viruses from other machines on the local network.
- Exploit of the Kiwi root account null-password by accidental ssh NAT mapping to the Kiwi on the user's Internet router (if you're going to open an ssh port to the Kiwi be certain to set a password for the root and "debian" accounts!)
1 and 2 seem likely but then you'd expect more than 8 of 500+ Kiwis to have been compromised. 3 and 4 are statistically less likely and probably account for the observed infection rate.Ultimately the distro on the Kiwi needs to be upgraded to Debian 9 or 10 with a root account password. But doing this in an easy, reliable manner that can be performed by the majority of our user base and not result in thousands of bricked Kiwis has yet to be developed.
The root no password thing is not exactly going to make it easy to see who was trying, if that was the route, at least if the root SSH was denied and the default SSH user was something like "kiwiusr" then we could spot attempts to any ssh server.
I like to see what usernames are tried SSH (or FTP) as it gives clues what systems are currently open by default.
I can imagine crafting a dummies upgrade guide and allowing for all customisations is going to be interesting.
Guess you could sell Debian 10 Beaglebone black as a hardware/software upgrade, just as long as the setup can be exported/imported (webdav or some other cloud upload?).
I should play with the beaglebone a bit more for exporting files, SCP, Fuse, SSHFS etc.
Maybe I'll get a black and fiddle with that I hate breaking a working radio.
Either way it prompted me to get on and segment the network a bit more, tried that five port external fibre router with one SFP copper adapter on the Kiwi, using the same (12V DC linear) source as the active antenna seems to be quiet enough (when the QRM is not bad).
Ideally the Beagle's 4GB eMMC filesystem should be split into two 2GB partitions so an entirely new distro could be downloaded and switched to. Some failover mechanism would have to be added to uboot (or someplace else) to make this scheme truly useful.
The split drive boot method sounds like a good solution, if the user wrote an image to a spare flash drive prior to the swap should be pretty easy to recover in the event of some serious issue.