What an amazing string of exploits! Especially the two unrelated API-side attacks being identified _twice_ in a two month period. Major props to both of y'all for investigating this!
I remember turning on myQNAPcloud on my NAS. less than 24 hours later it was encrypted with ransomware. Had to reset it, upload fresh firmware via TFTP, reformat the drives, and pull my backup tapes. Never again. Thankfully good old LTO4 tape saved the day.
I never trusted my NAS vendor enough to turn on the cloud access functionality - even though mine are neither Synology nor WD, I do feel some form of vindication :-P
As incredible as it was that these lads found these out, HOLY SHIT does it depress me about the overall security landscape of... everything? Did WD even try!?
TBH I'm more surprised at the Synology exploit - the WD one is more severe but WD isn't really a software company, they stumbled into this industry by selling hard drives and tacking on a basic NAS function, whereas Synology is fundamentally a NAS software vendor so they should know better.
Is WD releasing software that can be exploited because their peer review process doesn't cover the basic "identification, authentication, authorization model" incompetence or something else?
Unlike the WD exploitation, at least you had to be on the same local network to pull the device identifiers first in order to proceed any further with the attack. And if your local network is broken into, you've got bigger problems anyway! I'll stick with my VPN for remote access though.
was thinking the same. can someone clarify this? you cannot proceed unless you know the Mac address of the targeted NAS, right? So how exactly is this "easy" to obtain, as he claimed?
In fairness, they didn't present the Synology side as a fully realised RCE in the same way they presented the WD side, but I would strongly disagree that if your local network is broken into that you've got bigger problems than an attacker having complete access to your NAS. It's not *that* hard to get onto most users' LANs, with widespread dodgy IoT devices (Synology for instance has a general purpose NVR for security cameras, so there's going to be plenty of Synology devices sharing a network with remotely exploitable cheap IP cameras), and the thing is, one of the most valuable targets on any user's network is their NAS - that's what you want to hit if you want your ransomware to work, whereas a remote security camera exploit on its own just gets you a DDOS node and *maybe* some private images of your victim; it's going to be very rare for an attacker to actually use a remote security camera exploit to physically break into your home. We really need to dispense with this idea that the LAN *must* be considered a perfectly trusted environment - even my home LAN which is far more hardened than the average user still has weaknesses in the form of less trusted client devices and the only way I could eliminate those completely is by only attaching a single, extremely hardened computer to my network and severely limiting what I did on there, which just isn't viable. It's *nice* to have a secure LAN, and we should all take measures to secure our LANs, but we should also practice defence in depth and recognise that it's a very bad policy to depend entirely on the firewall of a cheap consumer router to defend our devices. (again, using my network as an example my NAS uses secured shares and TLS to communicate with clients even though the only way it's ever exposed to external devices is through a VPN, even local devices don't automatically have access to it and if a LAN only exploit was discovered I would expect my vendor to patch it, as should anyone else).
@@RandomUser2401 He did go into detail on how to get one of the other identifiers and mentioned it's a LAN based approach - once you're on the same LAN it's pretty trivial to spot the MAC addresses of other clients. See my other comment on why LAN only attacks are still significant, albeit not as bad as full on remote execution
@@bosstowndynamics5488 okay so the problem is shifted from obtaining the MAC to obtaining the relevant public IP and then breaking into it through some dodgy connected device. That sort of makes it easy for randomized attacks I guess by simply scanning public traffic and then trying to break into the respective LAN?
@@RandomUser2401 I think in practice, with no other exploits available in the cloud authentication chain, the real threat would be opportunistic attacks, and the simplest and most likely of those would be that ransomware includes an additional set of code to own your NAS and encrypt that too - as long as it landed on *any* computer on your network if it happens to spot a Synology it can attack that as well. More sophisticated setups might involve things like an automated system that deploys attacks against routers and then scans for targets from a library of candidates within a local network, then deploys a second stage attack against those. Notably, it's already quite common for ransomware to have additional payloads to increase the damage or try and avoid mitigation (most ransomware at the very least will scan for and encrypt network drives that are directly available from the infected system, for instance).
Western Digital engineer: ... great new product idea, a cloud with zero Auth, encrypted routing using public dns and public cert info on every user! CEohno: awesome i like the cut of your jib Perkins... so how much money did we save after firing our security team. Engineer: ... thanks, I'm Jerkins. You fired, i mean "downsized" Perkins...
The step 2, impersonating, should have been fixed on the cloud side like rejecting non-LAN IP address? But for compatibilty it seems can't just reject setting IP to another LAN address. Or have they just updated the whole protocol since they have alrealdy disabled cloud functionality for older versions?
This is exactly why you NEVER turn on these remote access features of your router or your NAS. These cloud based devices by design have to expose data to the web in order to work. If you turn on this tunnel that bores though your networks security your asking for trouble.
"If you turn on this tunnel that bores though your networks security your asking for trouble." I would slightly disagree with this statement - I would never in a million years trust a random closed source consumer vendor setup, but open standard VPN systems are technically boring a hole into your network but are widely considered secure as that hole is very small and difficult to exploit.
@@bosstowndynamics5488 You kinda missed the point of my statement. A VPN that you install and is open source and you are the end point to is vastly different then some cloud access feature in a modern NAS or router. It literally has to have some type of unsecured traffic in order to contact the vendor.
@@stevenchristenson2428 That's not actually, strictly speaking, true though. The cloud vendor could be providing a NAT traversal service for end to end encrypted traffic over any of a number of encrypted protocols, including a VPN tunnel. They probably aren't, because they're lazy, and even if they are they won't maintain it properly or are likely to make implementation errors like the ones described here, but it's not *fundamental* to the product
To respond to the query at 10:30 The European Commission exists separately to the Council and Parliament. The Commission's job is to go out and research issues and investigate things brought to them by European citizens, and present the findings of those investigations along with courses of action to the European Parliament who are all democratically elected individuals to vote upon. If those recommendations are passed into law the Council of Europe consists of the leaders of the States of the European Union to discuss specifics such as opt outs and alternative means of compliance. The EU didn't just wing this through the back door and pass it into law, it's been debated at multiple levels by experts and by politicians in multiple chambers.
@@some1and297I think this was typed as a response to an LTT clip video 😅, for some reason when the video changed over the comment got attached here instead of there 😂
I currently have on of those Abominations on my desk. To fix for a buddy. This whole device and architecture should be illegal - every one of those things should either get a proper NAS Firmware or be sent back und fully refunded. There is no reason for those things to exist.
What an amazing string of exploits! Especially the two unrelated API-side attacks being identified _twice_ in a two month period. Major props to both of y'all for investigating this!
I remember turning on myQNAPcloud on my NAS. less than 24 hours later it was encrypted with ransomware. Had to reset it, upload fresh firmware via TFTP, reformat the drives, and pull my backup tapes. Never again. Thankfully good old LTO4 tape saved the day.
Qnap have nice firmware but rest, I think we both know...
Ransomware for a NAS? so you see the Ransom note in the web UI?
It was in every folder on every share.
@@roland985 and how did you get the ransom message where to pay and so on?
@@RandomUser2401 Every folder and every share was encrypted with a ransomware note placed in each folder. Just a txt file.
I never trusted my NAS vendor enough to turn on the cloud access functionality - even though mine are neither Synology nor WD, I do feel some form of vindication :-P
Awesome talk! It's amazing how huge cloud platforms can make such poor assumptions about their system.
My God, this explanation was awesome
As incredible as it was that these lads found these out,
HOLY SHIT does it depress me about the overall security landscape of... everything?
Did WD even try!?
TBH I'm more surprised at the Synology exploit - the WD one is more severe but WD isn't really a software company, they stumbled into this industry by selling hard drives and tacking on a basic NAS function, whereas Synology is fundamentally a NAS software vendor so they should know better.
Is WD releasing software that can be exploited because their peer review process doesn't cover the basic "identification, authentication, authorization model" incompetence or something else?
Unlike the WD exploitation, at least you had to be on the same local network to pull the device identifiers first in order to proceed any further with the attack. And if your local network is broken into, you've got bigger problems anyway!
I'll stick with my VPN for remote access though.
was thinking the same. can someone clarify this? you cannot proceed unless you know the Mac address of the targeted NAS, right? So how exactly is this "easy" to obtain, as he claimed?
In fairness, they didn't present the Synology side as a fully realised RCE in the same way they presented the WD side, but I would strongly disagree that if your local network is broken into that you've got bigger problems than an attacker having complete access to your NAS. It's not *that* hard to get onto most users' LANs, with widespread dodgy IoT devices (Synology for instance has a general purpose NVR for security cameras, so there's going to be plenty of Synology devices sharing a network with remotely exploitable cheap IP cameras), and the thing is, one of the most valuable targets on any user's network is their NAS - that's what you want to hit if you want your ransomware to work, whereas a remote security camera exploit on its own just gets you a DDOS node and *maybe* some private images of your victim; it's going to be very rare for an attacker to actually use a remote security camera exploit to physically break into your home.
We really need to dispense with this idea that the LAN *must* be considered a perfectly trusted environment - even my home LAN which is far more hardened than the average user still has weaknesses in the form of less trusted client devices and the only way I could eliminate those completely is by only attaching a single, extremely hardened computer to my network and severely limiting what I did on there, which just isn't viable. It's *nice* to have a secure LAN, and we should all take measures to secure our LANs, but we should also practice defence in depth and recognise that it's a very bad policy to depend entirely on the firewall of a cheap consumer router to defend our devices. (again, using my network as an example my NAS uses secured shares and TLS to communicate with clients even though the only way it's ever exposed to external devices is through a VPN, even local devices don't automatically have access to it and if a LAN only exploit was discovered I would expect my vendor to patch it, as should anyone else).
@@RandomUser2401 He did go into detail on how to get one of the other identifiers and mentioned it's a LAN based approach - once you're on the same LAN it's pretty trivial to spot the MAC addresses of other clients. See my other comment on why LAN only attacks are still significant, albeit not as bad as full on remote execution
@@bosstowndynamics5488 okay so the problem is shifted from obtaining the MAC to obtaining the relevant public IP and then breaking into it through some dodgy connected device. That sort of makes it easy for randomized attacks I guess by simply scanning public traffic and then trying to break into the respective LAN?
@@RandomUser2401 I think in practice, with no other exploits available in the cloud authentication chain, the real threat would be opportunistic attacks, and the simplest and most likely of those would be that ransomware includes an additional set of code to own your NAS and encrypt that too - as long as it landed on *any* computer on your network if it happens to spot a Synology it can attack that as well. More sophisticated setups might involve things like an automated system that deploys attacks against routers and then scans for targets from a library of candidates within a local network, then deploys a second stage attack against those.
Notably, it's already quite common for ransomware to have additional payloads to increase the damage or try and avoid mitigation (most ransomware at the very least will scan for and encrypt network drives that are directly available from the infected system, for instance).
Western Digital engineer: ... great new product idea, a cloud with zero Auth, encrypted routing using public dns and public cert info on every user!
CEohno: awesome i like the cut of your jib Perkins... so how much money did we save after firing our security team.
Engineer: ... thanks, I'm Jerkins. You fired, i mean "downsized" Perkins...
First of all FU for WD DoS aaand thank you!
White hats off.
19:50 damn, maybe I should learn golang lol. That's a great list of perks from a dev perspective.
It is absolutely amazing, coming from a C/C++/Java/C# background and has become my favorite language.
The step 2, impersonating, should have been fixed on the cloud side like rejecting non-LAN IP address? But for compatibilty it seems can't just reject setting IP to another LAN address. Or have they just updated the whole protocol since they have alrealdy disabled cloud functionality for older versions?
This is exactly why you NEVER turn on these remote access features of your router or your NAS. These cloud based devices by design have to expose data to the web in order to work. If you turn on this tunnel that bores though your networks security your asking for trouble.
"If you turn on this tunnel that bores though your networks security your asking for trouble."
I would slightly disagree with this statement - I would never in a million years trust a random closed source consumer vendor setup, but open standard VPN systems are technically boring a hole into your network but are widely considered secure as that hole is very small and difficult to exploit.
@@bosstowndynamics5488 You kinda missed the point of my statement. A VPN that you install and is open source and you are the end point to is vastly different then some cloud access feature in a modern NAS or router. It literally has to have some type of unsecured traffic in order to contact the vendor.
@@stevenchristenson2428 That's not actually, strictly speaking, true though. The cloud vendor could be providing a NAT traversal service for end to end encrypted traffic over any of a number of encrypted protocols, including a VPN tunnel. They probably aren't, because they're lazy, and even if they are they won't maintain it properly or are likely to make implementation errors like the ones described here, but it's not *fundamental* to the product
"you guys rock" lol
To respond to the query at 10:30
The European Commission exists separately to the Council and Parliament.
The Commission's job is to go out and research issues and investigate things brought to them by European citizens, and present the findings of those investigations along with courses of action to the European Parliament who are all democratically elected individuals to vote upon.
If those recommendations are passed into law the Council of Europe consists of the leaders of the States of the European Union to discuss specifics such as opt outs and alternative means of compliance.
The EU didn't just wing this through the back door and pass it into law, it's been debated at multiple levels by experts and by politicians in multiple chambers.
Wait, did this comment get disconnected from the original video‽
I don't think so?
@@some1and297I think this was typed as a response to an LTT clip video 😅, for some reason when the video changed over the comment got attached here instead of there 😂
He’s 👍🏻
I currently have on of those Abominations on my desk. To fix for a buddy.
This whole device and architecture should be illegal - every one of those things should either get a proper NAS Firmware or be sent back und fully refunded.
There is no reason for those things to exist.