Kaydol

Flood göndermek, insanların floodlarını okumak ve diğer insanlarla bağlantı kurmak için sosyal Floodlar ve Flood Yanıtları Motorumuza kaydolun.

Oturum aç

Flood göndermek, insanların floodlarını okumak ve diğer insanlarla bağlantı kurmak için sosyal Floodlar ve Flood Yanıtları Motorumuza giriş yapın.

Şifremi hatırlamıyorum

Şifreni mi unuttun? Lütfen e-mail adresinizi giriniz. Bir bağlantı alacaksınız ve e-posta yoluyla yeni bir şifre oluşturacaksınız.

3 ve kadim dostu 1 olan sj'yi rakamla giriniz. ( 31 )

Üzgünüz, Flood yazma yetkiniz yok, Flood girmek için giriş yapmalısınız.

Lütfen bu Floodun neden bildirilmesi gerektiğini düşündüğünüzü kısaca açıklayın.

Lütfen bu cevabın neden bildirilmesi gerektiğini kısaca açıklayın.

Please briefly explain why you feel this user should be reported.

Hackers exploited 0-day, not 2018 bug, to mass-wipe My Book Live devices – Ars Technica

Hackers exploited 0-day, not 2018 bug, to mass-wipe My Book Live devices – Ars Technica

Benzer Yazılar

Yorum eklemek için giriş yapmalısınız.

22 Yorumları

  1. let me guess without reading the article: WD blames the users

  2. WD My Book Live sounds like a terrible product/premise to begin with. Why would anyone buy a storage device that directly connects to the internet with its security maintained and controlled by the vendor?

    And did you notice WD’s response to those impacted? ‘Come use our cloud storage instead’. Uh..no thanks.

  3. The string “php” appears far too many times in this article about a device which was allegedly attempting to implement some form of security by authentication.

  4. So…. Anyone think there will be any consequences for WD?

  5. Silly consumers weren’t shucking these drives as intended.

  6. What would make someone think their valuable data is safe exposed naked to the internet?

    This seems like a bad idea at many levels

  7. This was forced obsolesce.

    It was an inside job!!!

    /end crazy.

    /ramp up more crazy.

    They’re going to sell you one with a firewall-antivirus subscription next.

  8. So as a user, who believed had disabled remote access to my device, and was still impacted, does this mean WD are more liable to help me get my data back?

    If that commented code could have stopped this and didnt…they could at least help with recovery, but so far not even a peep from them

  9. What was the motive behind this? Seems like this level of exploit would allow for some very interesting money making opportunities especially for the criminally inclined. It’s rare these days to see attacks that are literally just destructive. Reminds me of the early days of viruses when everything was either a prank or else just fucked your shit up.

  10. A zero day on an embedded device… who would have ever thought… (extreme sarcasm)

  11. So how did hackers have access to these devices in the first place? It doesn’t sound like this was a cloud service exploit, were people exposing these directly to the internet?

  12. I would hate to be the dev with my name on that commit about now…

  13. We have to push laws to force companies to patch critical security vulnerabilities in timely manner. We can learn from the Auto industry how they handle Safety Open Recalls. I don’t see any difference in terms of responsibility.

    And it goes without saying, WD does not care about the customers. But as this security flaw shows, this kind of corporate “don’t give a shit since it’s ouf of warranty” behavior can come back and bite you in the ass. And it’s very bad in a long run

  14. They exploited a backdoor…. not really a bug. Somebody commented out the password verification in the code… lol.

    function get($urlPath, $queryParams=null, $ouputFormat=’xml’){
    // if(!authenticateAsOwner($queryParams))
    // {
    // header(“HTTP/1.0 401 Unauthorized”);
    // return;
    // }

  15. The developer probably commented out the authentication code to test something, then forgot to re-enable the code before starting the commit. No big deal. But…

    And then they forgot to check the diff to make sure they were committing what they intended to. Always check your diffs!

    And then nobody double-checked the commit before the code went live. No staging, nothing.

    So this was a procedural error on multiple levels.

  16. Hackers exploited 0-day, not 2018 bug, to mass-wipe My Book Live devices

    **Western Digital removed code that would have prevented the wiping of petabytes of data.**

    Last week’s mass-wiping of Western Digital My Book Live storage devices involved the exploitation of not just one vulnerability but a second critical security bug that allowed hackers to remotely perform a factory reset without a password, an investigation shows.

    The vulnerability is remarkable because it made it trivial to wipe what is likely petabytes of user data. More notable still was that, according to the vulnerable code itself, a Western Digital developer actively removed code that required a valid user password before allowing factory resets to proceed.

    Done and undone
    The undocumented vulnerability resided in a file aptly named system_factory_restore. It contains a PHP script that performs resets, allowing users to restore all default configurations and wipe all data stored on the devices.

    Normally, and for good reason, factory resets require the person making the request to provide a user password. This authentication ensures that devices exposed to the Internet can only be reset by the legitimate owner and not by a malicious hacker.

    As the following script shows, however, a Western Digital developer created five lines of code to password-protect the reset command. For unknown reasons, the authentication check was cancelled, or in developer parlance, it was commented out as indicated by the double / character at the beginning of each line.

    function get($urlPath, $queryParams=null, $ouputFormat=’xml’){
    // if(!authenticateAsOwner($queryParams))
    // {
    // header(“HTTP/1.0 401 Unauthorized”);
    // return;
    // }

    “The vendor commenting out the authentication in the system restore endpoint really doesn’t make things look good for them,” HD Moore, a security expert and the CEO of network discovery platform Rumble, told Ars. “It’s like they intentionally enabled the bypass.”

    To exploit the vulnerability, the attacker would have had to know the format of the XML request that triggers the reset. That’s “not quite as easy as hitting a random URL with a GET request, but [it’s] not that far off, either,” Moore said.

    Dude, where’s my data?
    The discovery of the second exploit comes five days after people all over the world reported that their My Book Live devices had been compromised and then factory-reset so that all stored data was wiped. My Book Live is a book-sized storage device that uses an Ethernet jack to connect to home and office networks so that connected computers have access to the data on it. Authorized users can also access their files and make configuration changes over the Internet. Western Digital stopped supporting the My Book Live in 2015.

    Western Digital personnel posted an advisory following the mass wiping that said it resulted from attackers exploiting CVE-2018-18472. The remote command execution vulnerability was discovered in late 2018 by security researchers Paulos Yibelo and Daniel Eshetu. Because it came to light three years after Western Digital stopped supporting the My Book Live, the company never fixed it.

    An analysis performed by Ars and Derek Abdine, CTO at security firm Censys, found that the devices hit by last week’s mass hack had also been subjected to attacks that exploited the unauthorized reset vulnerability. The additional exploit is documented in log files extracted from two hacked devices.

    One of the logs was posted in the Western Digital support forum where the mass compromise first came to light. It shows someone from the IP address 94.102.49.104 successfully restoring a device:

    rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 PARAMETER System_factory_restore POST : erase = none
    rest_api.log.1:Jun 23 15:46:11 MyBookLiveDuo REST_API[9529]: 94.102.49.104 OUTPUT System_factory_restore POST SUCCESS

    A second log file I obtained from a hacked My Book Live device showed a different IP address—23.154.177.131—exploiting the same vulnerability. Here are the telltale lines:

    Jun 16 07:28:41 MyBookLive REST_API[28538]: 23.154.177.131 PARAMETER System_factory_restore POST : erase = format
    Jun 16 07:28:42 MyBookLive REST_API[28538]: 23.154.177.131 OUTPUT System_factory_restore POST SUCCESS

    After presenting these findings to Western Digital representatives, I received the following confirmation: “We can confirm that in at least some of the cases, the attackers exploited the command injection vulnerability (CVE-2018-18472), followed by the factory reset vulnerability. It’s not clear why the attackers exploited both vulnerabilities. We’ll request a CVE for the factory reset vulnerability and will update our bulletin to include this information.”

    This vulnerability has been password-protected
    The discovery raises a vexing question: if the hackers had already obtained full root access by exploiting CVE-2018-18472, what need did they have for this second security flaw? There’s no clear answer, but based on the evidence available, Abdine has come up with a plausible theory—that one hacker first exploited CVE-2018-18472 and a rival hacker later exploited the other vulnerability in an attempt to wrest control of those already compromised devices.

    The attacker who exploited CVE-2018-18472 used the code execution capability it provided to modify a file in the My Book Live stack named language_configuration.php, which is where the vulnerability is located. According to a recovered file, the modification added the following lines:

    }

    function put($urlPath, $queryParams=null, $ouputFormat=’xml’){

    parse_str(file_get_contents(“php://input”), $changes);

    $langConfigObj = new LanguageConfiguration();
    if(!isset($changes[“submit”]) || sha1($changes[“submit”]) != “56f650e16801d38f47bb0eeac39e21a8142d7da1”)
    {
    die();
    }

    The change prevented anyone from exploiting the vulnerability without the password that corresponds to the cryptographic SHA1 hash 56f650e16801d38f47bb0eeac39e21a8142d7da1. It turns out that the password for this hash is p$EFx3tQWoUbFc%B%R$k@. The plaintext appears in the recovered log file here.

    A separate modified language_configuration.php file recovered from a hacked device used a different password that corresponds to the hash 05951edd7f05318019c4cfafab8e567afe7936d4. The hackers used a third hash—b18c3795fd377b51b7925b2b68ff818cc9115a47—to password-protect a separate file named accessDenied.php. It was likely done as an insurance policy in the event that Western Digital released an update that patched language_configuration.

    So far, attempts to crack these two other hashes haven’t succeeded.

    According to Western Digital’s advisory linked above, some of the My Book Live devices hacked using CVE-2021-18472 were infected with malware called .nttpd,1-ppc-be-t1-z, which was written to run on the PowerPC hardware used by My Book Live devices. One user in the support forum reported a hacked My Book Live receiving this malware, which makes devices part of a botnet called Linux.Ngioweb.

    A theory emerges
    So why would someone who successfully wrangled so many My Book Live devices into a botnet turn around and wipe and reset them? And why would someone use an undocumented authentication bypass when they already have root access?

    The most likely answer is that the mass wipe and reset was performed by a different attacker, very possibly a rival who either attempted to take control of the rival’s botnet or simply wanted to sabotage it.

    “As for motive for POSTing to this [system_factory_restore] endpoint on a mass scale, it is unknown, but it could be an attempt at a rival botnet operator to take over these devices or render them useless, or someone who wanted to otherwise disrupt the botnet which has likely been around for some time, since these issues have existed since 2015,” Abdine wrote in a recent blog post.

    The discovery of this second vulnerability means that My Book Live devices are even more insecure than most people thought. It adds authority to Western Digital’s recommendation to all users to disconnect their devices from the Internet. Anyone using one of these devices should heed the call immediately.

    For many hacked users who lost years’ or decades’ worth of data, the thought of buying another Western Digital storage device is probably out of the question. Abdine, however, says that My Cloud Live devices, which replaced Western Digital’s My Book Live products, have a different codebase that doesn’t contain either of the vulnerabilities exploited in the recent mass wiping.

    “I took a look at the My Cloud firmware, too,” he told me. “It’s rewritten and bears some, but mostly little, resemblance to My Book Live code. So it doesn’t share the same issues.”

  17. So was this just a giant troll? You’d be better off selling the zero-day I’d think.

  18. Not entirely sure if this is a good fit here but it seems like something a subset of us might need to know about.