Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 9 submissions in the queue.
posted by FatPhil on Thursday September 26 2019, @01:16AM   Printer-friendly
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


Original Submission

Related Stories

P2P Weakness Exposes Millions of IoT Devices 9 comments

P2P Weakness Exposes Millions of IoT Devices

A peer-to-peer (P2P) communications technology built into millions of security cameras and other consumer electronics includes several critical security flaws that expose the devices to eavesdropping, credential theft and remote compromise, new research has found.

The security flaws involve iLnkP2P, software developed by China-based Shenzhen Yunni Technology. iLnkP2p is bundled with millions of Internet of Things (IoT) devices, including security cameras and Webcams, baby monitors, smart doorbells, and digital video recorders.

iLnkP2P is designed to allow users of these devices to quickly and easily access them remotely from anywhere in the world, without having to tinker with one's firewall: Users simply download a mobile app, scan a barcode or enter the six-digit ID stamped onto the bottom of the device, and the P2P software handles the rest.

But according to an in-depth analysis shared with KrebsOnSecurity by security researcher Paul Marrapese, iLnkP2P devices offer no authentication or encryption and can be easily enumerated, allowing potential attackers to establish a direct connection to these devices while bypassing any firewall restrictions.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by JNCF on Thursday September 26 2019, @01:55AM (14 children)

    by JNCF (4317) on Thursday September 26 2019, @01:55AM (#898894) Journal

    "password."[sic - I suspect the '.' wasn't part of it, -- Ed.]

    While I appreciate the editor's clarification, it technically doesn't warrant a "sic." The inclusion of the period isn't gramatically incorrect, though it is confusing. Punctuation such as commas and periods are normally included in a quote like that. I sometimes break this rule intentionally when writing about technical topics, and I really wish it weren't a rule in general... but it is.

    • (Score: 3, Informative) by HiThere on Thursday September 26 2019, @03:24AM (1 child)

      by HiThere (866) Subscriber Badge on Thursday September 26 2019, @03:24AM (#898923) Journal

      In a programming context, quotes should include only and exactly that which is being quoted. Rules of general English are inappropriate.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
      • (Score: 3, Funny) by JNCF on Thursday September 26 2019, @03:55AM

        by JNCF (4317) on Thursday September 26 2019, @03:55AM (#898931) Journal

        Hmm, I must have missed that section of the AP Stylebook.

    • (Score: 3, Informative) by Sabriel on Thursday September 26 2019, @03:52AM

      by Sabriel (6522) on Thursday September 26 2019, @03:52AM (#898930)

      As you say, that is a general rule. However specific rules trump general rules and if the inclusion of punctuation would alter the meaning of a quotation itself - such as when quoting a password - then such punctuation should be placed outside the quotation marks.

      For example if the password is "password." then this sentence is grammatically correct. It is also grammatically correct to end this sentence with the statement that the password is "password.". In both cases this avoids ambiguity and does not break the rules of English grammar because the period in the password is not punctuative.

    • (Score: 1, Informative) by Anonymous Coward on Thursday September 26 2019, @05:06AM (7 children)

      by Anonymous Coward on Thursday September 26 2019, @05:06AM (#898947)

      "sic" just indicates that the passage is as written. It isn't particular to grammar.

      • (Score: 2) by JNCF on Thursday September 26 2019, @12:11PM (6 children)

        by JNCF (4317) on Thursday September 26 2019, @12:11PM (#899060) Journal

        I was googling for a direct AP Stylebook quote that I believed would contradict you, but according to their twitter they've dropped "sic" altogether.

        https://twitter.com/apstylebook/status/1124320764054863873?lang=en [twitter.com]

        • (Score: 0) by Anonymous Coward on Thursday September 26 2019, @03:41PM (5 children)

          by Anonymous Coward on Thursday September 26 2019, @03:41PM (#899168)

          What's with the AP stylebook trolling? This site isn't for general consumption and shouldn't be held to standards that would compromise its purpose.

          • (Score: 2) by JNCF on Thursday September 26 2019, @03:55PM (4 children)

            by JNCF (4317) on Thursday September 26 2019, @03:55PM (#899176) Journal

            The AP Stylebook is pretty much a standard styleguide for American journalism; it's known as "the journalist's bible" in the States. While I don't like it when this site phrases things in American-centric ways, such as saying "our government" instead of "the US government" in a summary, the spelling and grammar decisions make it very obviously American in style. I think it would be fine for this site to have a custom styleguide that deviates from the norm, but in lieu of that document existing the AP Stylebook is the most obvious reference document to go to when discussing formatting decisions made by journalists writing in an American style.

            • (Score: 1, Insightful) by Anonymous Coward on Thursday September 26 2019, @04:18PM

              by Anonymous Coward on Thursday September 26 2019, @04:18PM (#899186)

              When writing a reference/textbook, our publisher (c.1990) told us to use the "Chicago Manual of Style". Bought a copy and scanned through enough of it to get a feel for what was in there. The book is very well organized and it became a great reference, helping me convert my "engineers-writing-style" into something more consistent (and possibly more coherent also!)

              Then we submitted our book draft to the publisher...and their editor started to make changes that went against the Chicago Manual. Nothing against our editor, she was great, had been on a physics PhD track before she had to quit and get a job. This was about the local style guide in use by the publisher, which they hadn't bothered to tell us about.

            • (Score: 1, Interesting) by Anonymous Coward on Thursday September 26 2019, @07:58PM (2 children)

              by Anonymous Coward on Thursday September 26 2019, @07:58PM (#899281)

              I maintain that no such reference need be made or adhered to for such a small population, barring consistent issues with confusing news posts. I maintain that it's right to make clarifying edits even when the AP styleguide, or any other, would prefer to preserve confusion. I claim that it is very much inappropriate to use a mass-media style guide to present material to a small and ostensibly technical audience. And I refute that it is obvious, to the majority of the population here, to use the AP styleguide as a basis for such an audience.

              • (Score: 2) by JNCF on Thursday September 26 2019, @11:21PM (1 child)

                by JNCF (4317) on Thursday September 26 2019, @11:21PM (#899340) Journal

                I maintain that it's right to make clarifying edits even when the AP styleguide, or any other, would prefer to preserve confusion.

                I never contended that a clarifying edit shouldn't be made, I was just pedanting about the "sic" part of it in particular. I tried to be clear about that in my original post. Also, I think a paraphrasing of the confusing text that placed "password" in the middle of the sentence instead of at the end would have elegantly solved the problem without the need for a clarifying edit. I think that's what the AP would currently recommend, if I'm interpretting that tweet correctly (the last AP Stylebook I've read is about a decade out of date, how).

                And I refute that it is obvious, to the majority of the population here, to use the AP styleguide as a basis for such an audience.

                I wouldn't claim such a thing, but I also doubt that it's obvious to the readers Wired that the AP Stylebook should be the basis of editing decisions. Wired still uses it, because it's obvious to the authors that consistent editing choices across publications is desirable. Should less awareness of knowledge specific to the domain of journalism be expected of volunteer editors than paid journalists? Certainly. I'm just being pedantic (which isn't to say I'm wrong).

                • (Score: 0) by Anonymous Coward on Thursday October 03 2019, @03:39PM

                  by Anonymous Coward on Thursday October 03 2019, @03:39PM (#902313)

                  I wouldn't claim such a thing, but I also doubt that it's obvious to the readers [of] Wired that the AP Stylebook should be the basis of editing decisions. Wired still uses it, because it's obvious to the authors that consistent editing choices across publications is desirable.

                  You did notice that this story is taken, not from Wired, but from Threatpost, right? ;)

    • (Score: 2) by martyb on Thursday October 03 2019, @03:12PM (2 children)

      by martyb (76) Subscriber Badge on Thursday October 03 2019, @03:12PM (#902300) Journal

      Editing on the site is guided by this document on the Wiki: Editing Process [soylentnews.org].

      I found two sections which appear to be germane to this discussion.

      (1) Editing Process - Do's and Don'ts [soylentnews.org]:

      These are generally accepted best practices for editors.

      Do:

      • Check spelling and grammar
      • Check links
      • Check related stories for dupes

      Don't:

      • Post stories that you submitted
      • Add an "editor's note" with your opinion (put that in the comments)
      • Edit quoted material. [Unless doing so to provide clarity, using square brackets]

      (2) Editing Process - The Story [soylentnews.org]:

      Do not correct source material. If the source web page or document says something - that is how it will be published. As an editor you can decide whether it is a simple spelling mistake (in which case put '[sic]' immediately after the error). Do not correct English dialect differences. As long as the summary is consistenly written in US-English or UK-English, it is correct. Do not change the spelling of source material to suit your own particular dictionary. If, for example, the material is published in UK English, changing words to US English (or vice versa) can significantly change the meaning of what is being said. You edit the summary - not the source material. For other errors an Editor's Note is probably more appropriate.

      In short, the presence of "[sic]" is only intended to convey to the reader confirmation that the editor has accurately conveyed the quoted text; that the text which precedes this marker is exactly as it was in the source and is not the result of an editorial or transcription error.

      Just to muddy the waters a bit. Conventions for US English and UK English differ. Whereas the norm for the US is to include punctuation within the quotation marks, in the UK the norm is to place punctuation external to the quotation marks. That's the general summary, but when dealing with technical information, like text that must be entered verbatim into a field in an application. In that specific case, punctuation should always be placed external to the quotation marks so as to remove all possible doubt whether said punctuation is or is not part of what should be typed into that field.

      Here is a hypothetical example:

      Setting up your router. Upon initial powerup of your new router, you will be presented with a login screen. The device is shipped from the factory with defaults that should be changed. The first time you log in enter a Userid of "admin" and a Password of "password."

      This may be correct by general rules of punctuation, but in this particular situation, it introduces ambiguity and confusion. Does the user type "password." or "password" in the text entry field? This is solved by the simple rule that text to be entered into a computer is exactly as it appears between the quotation marks:

      Setting up your router. Upon initial powerup of your new router, you will be presented with a login screen. The device is shipped from the factory with defaults that should be changed. The first time you log in enter a Userid of "admin" and a Password of "password".

      Relatedly, consider how to present to the reader a long URL that needs to wrap across two lines — should it be hyphenated, or not? Again, when specifying information which must be entered verbatim into a computer, it is best to not introduce any characters that would be otherwise required by the general rules of formatting.

      Lastly, I've been with this site since the beginning, and an editor since 2 months after it launched. In all that time I do not recall ever hearing that we should use the "AP style guide" on this site. Its contents, as well as that of the Chicago Manual of Style (and possibly others) may have been used to inform the site formatting guidelines. So, I'll admit that it might have been discussed in the very earliest days of the site, but I recall no mention of it within the past few years.

      /me hits "Submit" and waits for Muphry's Law [wikipedia.org] to appear and reveal itselves. =)

      --
      Wit is intellect, dancing.
      • (Score: 2) by JNCF on Thursday October 03 2019, @03:48PM (1 child)

        by JNCF (4317) on Thursday October 03 2019, @03:48PM (#902321) Journal

        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.

        As an editor you can decide whether it is a simple spelling mistake (in which case put '[sic]' immediately after the error). Do not correct English dialect differences. As long as the summary is consistenly written in US-English or UK-English, it is correct. Do not change the spelling of source material to suit your own particular dictionary. If, for example, the material is published in UK English, changing words to US English (or vice versa) can significantly change the meaning of what is being said. You edit the summary - not the source material. For other errors an Editor's Note is probably more appropriate.

        In short, the presence of "[sic]" is only intended to convey to the reader confirmation that the editor has accurately conveyed the quoted text; that the text which precedes this marker is exactly as it was in the source and is not the result of an editorial or transcription error.

        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.

        Setting up your router. Upon initial powerup of your new router, you will be presented with a login screen. The device is shipped from the factory with defaults that should be changed. The first time you log in enter a Userid of "admin" and a Password of "password."

        This may be correct by general rules of punctuation, but in this particular situation, it introduces ambiguity and confusion.

        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

          by martyb (76) Subscriber Badge on Thursday October 03 2019, @11:42PM (#902475) Journal

          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.
  • (Score: 0) by Anonymous Coward on Thursday September 26 2019, @11:59AM (1 child)

    by Anonymous Coward on Thursday September 26 2019, @11:59AM (#899055)

    Using telnet, are they out of their minds? Weak passwords with hardcoded credentials, nowadays should be used securely over vulnerable sshd implementation.

    • (Score: 2) by DannyB on Thursday September 26 2019, @03:13PM

      by DannyB (5839) Subscriber Badge on Thursday September 26 2019, @03:13PM (#899147) Journal

      If you can't understand how to set up sshd, then at least run telnet on a non standard port so that nobody would ever be able to find it.

      (note I did NOT use any <no-sarcasm> tags.)

      --
      If a lazy person with no education can cross the border and take your job, we need to upgrade your job skills.
(1)