SoylentNews is people
SoylentNews
from the the-S-in-IoT-stands-for-what? dept.
Million+ IoT Radios Open to Hijack via Telnet Backdoor:
Attackers can drop malware, add the device to a botnet or send their own audio streams to compromised devices.
Imperial Dabman IoT radios have a weak password vulnerability that could allow a remote attacker to achieve root access to the gadgets’ embedded Linux BusyBox operating system, gaining control over the device. Adversaries can deliver malware, add a compromised radio to a botnet, send custom audio streams to the device, listen to all station messages as well as uncover the Wi-Fi password for any network the radio is connected to.
The issue (CVE-2019-13473) exists in an always-on, undocumented Telnet service (Telnetd) that connects to Port 23 of the radio. The Telnetd service uses weak passwords with hardcoded credentials, which can be cracked using simple brute-forcing tactics. From there, an attacker can gain unauthorized access to the radio and its OS.
In testing, researchers said that the password compromise took only about 10 minutes using an automated "ncrack" script – perhaps because the hardcoded password was simply, "password."[sic - I suspect the '.' wasn't part of it, -- Ed.]
After logging onto the device, researchers were able to access the "etc" path with root privileges to request various file contents, including the full system password shadow file, the group password shadow file, the USB password and the httpd service password containing the "wifi cfg" file with unencrypted information on the wireless LAN key.
"By now we had a full access to the file system with httpd, Telnet and we could as well activate the file transfer protocol," according to an advisory from the Vulnerability Lab on Monday. "Then we watched through the local paths and one was called "UIData". In the UIData path are all the local files (binaries, xml, pictures, texts and other contents) located which are available to process the Web GUI (Port 80 & 8080). For testing we edited some of the folders, created files and modified paths to see about what we are able to change in the native source of the application. Finally we [were] able to edit and access everything on the box and had the ability to fully compromise the smart web radio device."
Adding insult to injury, the researchers also found there to be a second vulnerability (CVE-2019-13474) in the AirMusic client onboard the device, which allows unauthenticated command-execution. [...]
Sounds almost as secure as my NAS - anyone want a go, it's here.
Previously:
P2P Weakness Exposes Millions of IoT Devices
(Score: 2) by JNCF on Thursday October 03 2019, @03:48PM (1 child)
Thanks for linking that wiki document, I was unaware of it! In light of that existing, I agree that the AP Stylebook is irrelevant. Before saying anything else, I'd like to stress once again that I'm just being pedantic here. I honestly didn't think any editors would care enough to type up this sort of response.
Italics emphasis yours, bold emphasis mine. I feel like the second piece of bold text isn't actually equivalent to the first piece of bold text; if a man was named "Johhn," and an editor wanted to convey that the double "h" was not an editorial or transcriotion error, "[sic]" would be inappropriate as the double "h" was not actually a spelling mistake. It seems to me that this wiki document (as currently written) is prescribing the use of "[sic]" only for spelling errors -- even a hisheard transciption would be out of scope, as the error was not in spelling.
I agree that it causes confusion, but I don't think that makes it a spelling error. I agree that this confusion warrants a comment by the editor (if rephrasing the confusing sentence outside of a quote block is out of the question), but I don't think that editorial comment should include "sic" based on a strict interpretation of the guidelines you linked.
(Score: 2) by martyb on Thursday October 03 2019, @11:42PM
Yes, pedantic++!
Methinks you may be reading too much into the excerpt I quoted. My take is that if there is the perception on the part of the editor that there is an error in the quoted source, then "[sic]" should be used to inform the reader that "Yes, I noticed this too, and I *have* correctly copied it here exactly as it appeared in the original source."
As for the focus on the word spelling, I take that to be an example of the kind of error one might encounter where a "[sic]" is warranted, rather than an explicit enumeration of the only reason. Capitalization errors ("Soylentnews" instead of "SoylentNews"), word order swapping ("I went the to store." instead of "I went to the store.") are other examples where I believe it could be apropos to include "[sic]".
There is an alternative that I have used in a limited number of occasions. In the case of the latter example I just gave, instead of "I went the to[sic] store.", I might, instead write: "I went [to the] store."
Lastly, (1) these are guidelines and (2) we are volunteers who may not necessarily have a professional background in copy-editing. In my own case, I have over 30 years' experience in software QA and test. This is not relegated strictly to testing software! It also included reviewing technical specifications from high-level design, functional design, logic specifications as well as user's guides and technical references. Then add reviewing all text that may be presented to a user in the course of using the product.
There is an old saying to the effect of "If you really want to understand something, try explaining it to someone else." Thanks for helping me clarify in my mind when and how I would apply it.
And for a laugh, if a man was incorrectly quoted as to the command he gave his dog to chase an intruder, would we report that as "He told his dog "Sick[sic] 'em!"
Or, even better, were someone to comment on this whole discussion with "That's sic!" it should obviously be reported here as "That's sic[sic]!"
=)
Wit is intellect, dancing.