Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday March 10 2017, @02:52AM   Printer-friendly
from the Hey!-You!-Get-off-of-my-Cloud! dept.

Western Digital My Cloud NAS devices have again been found wanting in the security department, as two set[s] of researchers have revealed a number of serious flaws in the devices' firmware.

WD My Cloud is meant to be a private cloud environment hosted at home or at a small organization's office, and can be accessed either from a desktop located on the same network or remotely, with a smartphone, from wherever else in the world. Users can interact with it either via the administrative user interface or an application (that uses a RESTful API).

Zenofex, a member of the Exploitee.rs team, revealed the existence of a login bypass issue, several command injection flaws, and a number of other bugs on Saturday.

Then, on Tuesday, researchers with the SEC Consult Vulnerability Lab published a security advisory warning about:

  • The existence of an unauthenticated OS command injection vulnerability
  • The existence of an unauthenticated arbitrary file upload flaw (that could allow an attacker to upload a malicious file or script with OS commands into the devices' webserver), and
  • The fact that the devices' firmware has no anti-CSRF mechanisms.

"Due to [no anti-CSRF mechanisms], an attacker can force a user to execute any action through any script. As the [OS command injection and unauthenticated arbitrary file upload vulnerabilities] do not need authentication, those can be exploited via CSRF over the Internet as well!", the researchers noted.

Source:

https://www.helpnetsecurity.com/2017/03/08/western-digital-mycloud-nas-vulnerable/


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.
  • (Score: 3, Interesting) by FatPhil on Friday March 10 2017, @06:33AM (1 child)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Friday March 10 2017, @06:33AM (#477277) Homepage
    You wouldn't need to mitigate against bad actors hijacking authenticated sessions if you didn't chose as your control interface an environment which was deliberately set up to have no security at all. A browser is like a terminal with any number of wireless keyboard receivers filling all and sundry USB ports - you really don't know where any particular input (request) is coming from. CSRF is elastoplast over this hole.

    I'll note that many sites suffer from same-site-request state inconsistency issues too - what you do in one tab will affect what happens in another tab on the same site. The cookie model is flawed, and has been since day 1. It's never been a "session" identifier, despite the name of all those cookies, it's never been more than a browser identifier. That's why CSRF mitigation doesn't use cookies. You remember those old "&sessionid=XXXXXXXXXXXXXX" carbuncles on URLs that magically disappeared when cookies took over - they were more secure. We've gone backwards.

    We have point-to-point input/output session control already - they're called (pseudo-)ttys. Best of all, you can even multiplex them if, and only if, you so desire.

    So the real wtf is mindlessly defaulting to control via HTTP. I blame the pointy-clicky generation who think that typing two bits of text into some webpage input boxes and clicking a button is simpler than adding a two-field line to a text file or running a simple command with 2 parameters.

    And git orf moi lorn!
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 3, Insightful) by gidds on Friday March 10 2017, @01:25PM

    by gidds (589) on Friday March 10 2017, @01:25PM (#477335)

    I blame the pointy-clicky generation who think that typing two bits of text into some webpage input boxes and clicking a button is simpler than adding a two-field line to a text file or running a simple command with 2 parameters.

    While there's something in that, if I may play Devil's Advocate for a minute:

    A web style interface has several advantages.  For example, discoverability: a web page can include prompts and other information explaining what needs to be input, and why; a command can't do any of that, and while text files can include some info, often it's missing or easily confused with the input.

    And validation: a web page makes it very obvious where you should type (by preventing you from typing anywhere else), and provide a default answer; it can also (with the use of JS or server-side validation or whatever) make it very clear when the input isn't acceptable.  Commands can't do any of the former, and text files can't do any of the latter.

    Expert knowledge mitigates those factors to a degree, of course.  But we're not talking about something people will be using day-in, day-out and have a chance to become expert in — we're talking about a page that most people won't need to use more than a few times, briefly.  So an expert interface really isn't appropriate; it needs something suitable for casual users.

    Now, none of that need be implemented by a browser program, or in HTML.  In fact, that style of interface goes right back to menu-driven terminal-screen programs.  — Of course, running a program would introduce even more security issues than a web page (in addition to a shedload of platform dependencies), so that's no solution.

    But while I agree that the implementation of web-page control leaves a lot to be desired, the web-style interface seems in many ways rather better than most of the alternatives.

    --
    [sig redacted]