Microsoft Windows RCE Vulnerability Gives an Attacker Complete Control | Hacker News Reader

Microsoft Windows RCE Vulnerability Gives an Attacker Complete Control

synack.com

166 pointsmedia_hacker82 comments

Before you dismiss this as not serious due to the fact that it needs a server to be compromised first: it isn't rare at all to see companies giving access to each others' servers for instance to help with the maintenance of bespoke applications, or for situations where systems administration is outsourced. And of course those are exactly the kind of clients that are at risk of having their infrastructure compromised in the first place, otherwise they wouldn't have to outsource this work. And once you manage to gain access to the support teams' computers you also now have a gateway into all the other machines that they support. So this has the potential to rapidly escalate to something far more serious.

> once you manage to gain access to the support teams' computers you also now have a gateway into all the other machines that they support

Speaking of which, what is everyone here’s view on allowing passwordless sudo on Linux servers?

In my mind, if someone has already gained access to my user on the server, which has sudo privileges, they are only a couple of steps away from be able to take control over the server anyways. So I allow sudo without password on my servers.

sudo password is basically nothing but an annoyance.

Likewise, my ssh keys are also not password protected. If you are able to read my ssh keys, you have already won anyways. No point to me in having a password on them.

Where I do take extra steps instead include:

- I disable password based authentication for sshd, allowing only keybased authentication.

- On some servers I have sshd listening on WireGuard interfaces only.

- My personal devices use full disk encryption.

- I lock computers and other devices when I walk away from them.

- I use 2FA for any third-party services of importance such as mail etc, preferring TOTP/HOTP if available. Or SMS based if that’s the only option even though it’s not very good it’s something.

- I use an adblocker in the browser on my computers.

- I am careful not to get tricked by phishing emails, phishing SMSes and other scam messages.

- I install software from trusted sources mainly.

- I use an iPhone, not Android.

I’m pretty satisfied about my own computer security.

Next step I need to handle is proper backups. I have too many files that are stored in n=1 locations. I have some of the most important files in n>=2 locations, but still there are many important files that I don’t.

All security is just putting roadblocks in place to buy you time to notice and to make you an unattractive target, same physically as digitally (you don't really think your front door lock will keep someone out that really want in, right?).

Passworded sudo is just another roadblock to give you more time. Passwordless means instead of the attacker getting local root and then having to find an exploit, they immediately get to escalate to root. For very sophisticated attackers, it may by a trivial difference in time, but for unsophisticated ones it may mean they don't get root to do more damage.

And given that sophisticated attackers are ones you can't really guard well against without a whole department devoted to it, unsophisticated ones are probably ones you should really make sure not to ignore.

> you don't really think your front door lock will keep someone out that really want in, right?

I recently had the - unfortunate - opportunity to put this to the test. The house I live in has the highest grade burglary protection that you can still buy for normal money (courtesy of the previous owner). It still only took me 35 minutes to break into it when I accidentally closed the door behind me when there was nobody else home. This kind of surprised me, because I didn't have access to any tools at all, just the stuff that was laying around in the garden (some sticks and a little bit of steel wire). And all that without breaking anything, if that constraint would not have been there the 35 minutes would have been reduced to 30 seconds, tops.

Later I figured out three other ways to get in without any damage, but most of those would have cost a bit more time.

I live in a rather modern European apartment/condo and I don't think this would be true for my home at all. Sure, with the right tools you can get windows or doors open, but it will be very loud and not that easy. Windows are triple glazed (for insulation, not protection) and they have a fair amount of locks on all sides (can be annoying as they won't close if any of those are blocked by dirt or leave).

If you just close the door without locking it, it's possible to open them without causing too much damage. But I heard from neighbours who got locked out that if you have your door locked, even a locksmith will at least need to destroy the lock, potentially even part of the door, to get inside.

There's no such thing as perfect protection, but most thieves will ignore objects that take longer than a minute or two to break in to. There are too many alternatives and any minute spent at the door increases the risk of detection.

Also, apart from doors or windows there are no openings. There's ventilation but the diameter is way too small to crawl through. And access from parking is secured the same way as through the front door.

So yes, I think a front door lock will keep out thieves. Not because it makes it impossible but because it's just not worth it. Same as a well protected server all but keeps out intruders. Unless you're a very high value target, they go after easier targets first.

Regular viewers of The Lock Picking Lawyer on youtube know how trivial it can be to bypass many common locks. Especially if you pickup a 10 dollar tool for the job. And I don't mean trivial for the LPL, I mean just trivial for a lay person who is aware of the vulnerability.

Unrelated, here is my favorite LPL video where a locksmith calls bullshit and challenges LPL to a duel: https://www.youtube.com/watch?v=NSuaUok-wTY

Oh that's hilarious. He could have done four in that time.

Apartments are probably harder than houses, fewer points of entry pretty much ensure that. But I've lived in apartments as well and in fact a few years ago in Bucharest I had to do something quite similar and that worked just fine as well. It all depends on how much you know about how stuff is put together to be able to spot the weak points in a structure. But a properly designed and implemented security layer for an apartment would be hard or even impossible to crack without damage. The devil is in the details though and compared to a thief, if it is your own place you have a lot of motivation not to damage it and a lot of time.

I have one "shut myself" out of my apartment when I have replaced the tag and a draft closed the door - when I realized, I don't have any keys. I knew, one window was angle opened in the kitchen right next to the balcony. I asked my neighbours, if I could climb over. It was the third floor, so I kind of hesitated, but there were multiple robust things I could hold onto. I used my belt to move the handle of another window 90° so it would open like a door through just the 5 cm opening at the top of the other window.

Nobody saw me, nobody asked anything. I could perhaps climb to the balcony easily even though I don't do any climbing otherwise. After this, I never left the apartment with any angle-opened window after that.

What is your house made of? How can you have multiple ways of entering a house without any damage if you have walls, doors and windows? What else is there?

> How can you have multiple ways of entering a house without any damage if you have walls, doors and windows?

Given that it is pretty trivial to find out where I live I'm not going to write that up here, you're going to have to take my word for it. But the hacker mentality applies to houses just as it applies to servers. You just need to think a bit more adversarial.

Doors and windows are designed to open, and frequently they don't lock automatically (or the lock is VERY insecure). There are crawl spaces, attics, mail slots, balconies, garage doors, etc. that frequently connect the outside to the inside.

Don't forget the chimney. Ho ho ho!

Two out of three ;)

> Passworded sudo is just another roadblock to give you more time.

The problem with this world-view is that it's a fallacy. You're assuming that people won't be bothered by having to re-type their password all the time, and just implement a "secure" script using a setuid bit instead.

Now someone else intentionally adds the ability to allow that script to execute arbitrary commands and you've got a vulnerability with passworded sudo that would have never happened with passwordless sudo.

I've seen that same story happen countless times in the real world. E.g. a company I worked for went from a "bastion" login system (authenticate once) for the sysadmin "run a command on the fleet" interface of last resort to requiring "re-authentication on login", which now needed a re-login with a OTP for each machine, in a datacenter with quite a few machines.

That's conceptually the same as insisting on passworded sudo in terms of security. Guess what happened next in that setup? No points for "sysadmins just got used to re-typing their passwords in the for-loop" :)

> The problem with this world-view is that it's a fallacy.

There's nothing fallacious about the concept that security controls are just roadblocks. There is no such thing as perfect security for a system that requires someone to be able to access or use it. All security controls do is provide time and/or notification of someone trying to break in, if all goes well. Then you can hope to mount a more active defense of some sort if needed.

> You're assuming that people won't be bothered by having to re-type their password all the time, and just implement a "secure" script using a setuid bit instead.

Obviously there's a trade off for how cumbersome it is to use something in an authorized manner and how much people will attempt to work around that inconvenience. What is a fallacy is that any inconvenience in the same of security is not worthwhile.

In many configurations of sudo shipped by default in common distros, it caches your auth for that tty for a number of minutes, so after you auth you don't have to auth again for a while. You can easily change this, and make it so that after you auth in a tty, you won't have to auth again for 24 hours if you wanted. You would still have quite a bit of protection from attackers (at least those that weren't at an unlocked screen of yours with one of those terminals), and entering a password once a dayis probably acceptable to most people (in reality, once a day per terminal they want to use it in, but it's not hard to keep one terminal open for secure use).

> Now someone else intentionally adds the ability to allow that script to execute arbitrary commands and you've got a vulnerability with passworded sudo that would have never happened with passwordless sudo.

It's hard to protect against stupidity. Either train people to not to stupid things, or if your security policy is actually too onerous, then reassess what the correct policy should be and implement it. To be clear, I doubt the correct policy is "let's just turn off all the security because we're lazy".

> That's conceptually the same as insisting on passworded sudo in terms of security.

It's easy to say it is, because almost everything is conceptually the same thing if you boil them down to a few related concepts and attributes and then ignore the magnitude and impact of those things. I mean, shooting someone with a Nerf gun and shooting someone with a Glock are conceptually the same things, right?

So, please, let's not act like having to enter your password once every few minutes when needed for root access (or longer, if you configure it to) is equivalent to jumping through multiple systems, authing additional times at each level, and requiring OOB auth additionally. If you're really annoyed by sudo, just "sudo bash" and keep the terminal open. At least you still get some protection from local user access privilege escalation.

Passworded ssh keys can be valuable - if I steal your laptop while it’s on, I can use DMA hacking or frozen ram kind of techniques to extract secrets out of memory. If your SSH keys have a password on them, I have a limited time to perform said attacks.

For that reason, I’d prefer passphrase backed keys, even if they had very long (36h+) expiry time.

Edit: one cool hack I use is a conplex FDE password, but relatively simple /etc/shadow password - this saves a huge amount of effort.

If you're a sysadmin for a large company or if you're a public person then I'd agree, but I believe for 99% of us, no one would spend the time to perform these attacks on stolen hardware. And even for large companies, they'd just look for the next sysadmin who has their password on a post-it on the laptop or in their bag (still happens enough).

Yeah but op was questioning real security model without context. I don’t disagree with you, security and threat models are highly contextual.

It really depends. There's honestly a really big difference between user and root on Linux, so handing root over is probably not ideal. That said, how you deal with this is up to you and very specific to your infrastructure and security posture.

For example, the obvious question is probably "why is anyone sudo'ing". A lot of operational capabilities don't need sudo. Some do.

Rather than handing over passwordless sudo, you can provide binaries that can execute with the required permissions but provide a much more granular interface. For example, if you need to take a memory dump of a service the binary could be set up to only allow that capability and to only work on a set of services.

Further, you may want to audit sudo access but allow it. If you remove the need for root capabilities for engineering purposes you should see sudo very rarely and be able to alert on that - but obviously this assumes you have an instrumentaiton pipeline set up.

Speaking of instrumentation, it's one of the major reasons why you don't want to just hand root over. An attacker with root can more or less just turn instrumentation off. An attacker without root is auditable.

For your specific situation your current security posture could be fine. For a large company they may want to do more.

The tl;dr is really that, yeah, on some default Linux system where you assume an attacker is executing within your user already, a password on sudo isn't gonna help much. But obviously you should harden that server, and a big part of that is going to be "how do I keep the attacker from getting root".

> In my mind, if someone has already gained access to my user on the server, which has sudo privileges, they are only a couple of steps away from be able to take control over the server anyways.

This seems like sound logic to me. If you have write permission to their bashrc, it's trivial to change their path to include a keylogging wrapper for sudo. The next time they use sudo, you have their password. If an attacker has gotten that far, a password on sudo seems like closing the barn doors after the horses already ran off.

Yeah but you can harden against that. You can:

1. Audit writes to paths like bashrc (I've written this alert and many others like it)

2. Audit writes from processes under uid X to files in uid Y's home

3. Limit the need to sudo in the first place

4. Add a TOTP auth to sudo

5. Limit the ability for arbitrary processes to write to arbitrary files (containerize your shells, services, etc).

The thing is that all of the above assume the attacker isn't already root. If the attacker is root, this all becomes a lot harder.

Alright, instead, knowing this, I shall simply change the configuration of your terminal emulator to use a wrapper script I wrote. It'll inject a script into the shell to alias sudo to my evil variant. The evil variant will instead of calling whatever you wanted with sudo instead call itself and first worm into the system with root, then continue execution with what you wanted. A simple scan should reveal running services and the executable will disguise itself as those, ideally by writing to files that the original sudo command would have written to. Like, if you sudo crontab -e, then I shall simply worm into your crontab and wrap access to it to hide the actual contents. Once that is done I can go into manipulating your audit to hide myself before continuing with more nefarious things.

I'm not sure I understand this attack. You're some process under a uid, say 1000. I SSH into the box and get a shell at uid 1000.

You're describing an attack where you configure my terminal to use a wrapper script? What exactly does that entail?

Well for SSH you can simply edit the authenticated_keys file to get what you want.

Sorry, I'm still not understanding your attack. As a user on the system, which files are you writing to exactly in order to execute this attack you've described?

Any configuration files of programs the user might call, such as editors, ssh, terminal emulators, shells or anything the user regularly executes.

Every binary that loads data from the user directory for user configuration is a vector for further inserting oneself into the system.

The spellcheck function of Nano can be exploited to spawn a subprocess that takes over the session. When you exit Nano, you're exiting this new subprocess and end up in a shell that has been manipulated.

Same for Vim.

SSH can be manipulated into replacing your shell easily by editing authorized_keys.

If a program has write access to your home directory, you cannot trust the shell you open.

Even something as innocous as git status being included in your prompt can be abused to gain control of your shell session. Once you have that you just wait for sudo to be entered or you manipulate the shell to execute an attacker's code instead of sudo when called.

I'd be interested in hearing more about the specific for some of these, but others seem unlikely to work.

For example, there's no reason for a user to have read, let alone write, access to authorized_keys.

Read and write access for users is way overly permissive by default, but it's really easy to fix that.

I do agree that you can't trust the shell if a user is compromised though. But this is about preventing an attacker from gaining root access, which means you now can't trust the entire system (since they can just shut off security controls).

Also keep in mind that all of these described attacks require performing auditable actions. If an attacker can trivially, quickly escalate, you can't trust your auditing.

i mean sure there will be several dozens ways to compromise your machine once your user account is wide open already... but allowing any script or software to run any command privileged without any questions asked? there is certainly a risk attached to that and not even necessarily related to an active attack... you are one badly written script away from doing something dumb without even noticing it...

and not having to confirm anything to use your ssh keys means not only your machine is compromised but all of those that those keys allow access to are potentially compromised too now... i use an ssh-agent (gpg-agent implementation) to only ask once at the start of my session for the password and every time for confirmation of usage or after some time without usage it will ask for the password again. its not annoying at all...

Optimally, password authentication would be hardware protected. Meaning, for instance, there was a dedicated LED on your system that you'd need root rights to toggle, and any password request thrown up would need to light up that LED to indicate that it's the actual dialog, rather than a fake. - A similar, less invasive solution could be randomizing the password dialog background color when your user account is set up.

Now, given we don't do any of that shit, it's trivially easy to hijack a root/ssh key password request by just faking the dialog. In that sense, you may as well go passwordless. However, IMO going passwordless is tantamount to admitting not just that our security sucks, but that our security is going to suck forever. Seems kind of defeatist.

It's not just sudoers accounts, the reality is that privilege escalation vulnerabilities are very common on Linux systems, particularly if you run uncommon drivers. So any sort of code execution, even on an unprivileged account is generally game over.

Qubes OS does exactly that [0], but the security actually relies on virtualization there.

[0] https://www.qubes-os.org/doc/vm-sudo/

> In my mind, if someone has already gained access to my user on the server, which has sudo privileges, they are only a couple of steps away from be able to take control over the server anyways. So I allow sudo without password on my servers.

Sudo can use root password instead of user password. Possibly other auth mechanisms also. It may be better to fine tune sudoers than to leave it wide open.

> Likewise, my ssh keys are also not password protected. If you are able to read my ssh keys, you have already won anyways. No point to me in having a password on them.

None of this is ever so black and white. If I have your ssh keys, haven't I only won if you're not also using a password? Otherwise, all I have is your ssh keys, which granted, is bad, but defense-in-depth, no?

> If I have your ssh keys, haven't I only won if you're not also using a password?

In general if someone has enough access to get your ssh private keys, they have enough access to log the next time you type the password.

> Otherwise, all I have is your ssh keys, which granted, is bad, but defense-in-depth, no?

Everything is trade offs. In order for the password to not be completely worthless, it has to be complex enough to not be trivially broken by password crackers. But then it's long and hard to type. If you have to type it a lot, and all it's buying you is that the attacker has to wait for the next time you type the password, that's a poor cost benefit ratio.

If someone has my private keys because they stole my laptop, then a keylogger will do them no good, and the password will be a valuable layer of defense.

It is a good idea to use disk encryption anyway.

Yes, that too!

Disk encryption, aggressive lock screen timeouts, etc -- that's all good stuff in addition.

But the point is that defense-in-depth works, and passwords can be a meaningful part of the strategy.

> In general if someone has enough access to get your ssh private keys, they have enough access to log the next time you type the password.

Isn't this only true assuming the private key isn't backed up somewhere?

You mean assuming they don't get your private key from the backups.

But then you want to encrypt all the backups and not just the private key, right?

You should still use passwords with SSH keys to ensure that they're encrypted on disk. An SSH agent makes the user experience not annoying, so there's no point in opting out of the extra security.

You can switch to short-lived signed SSH keys and protect the CA key with all the measures.

The far more interesting scenario is via the hyper-v console viewer, you could call OVH or Azure or whoever and get support to console your machine, then escape your VM onto their hyper-v host.

This is not a Windows RCE vulnerability. It is a vulnerability of RDP client (not even the server). To hack one would have to convince you to try connecting to a malicious server.

> To hack one would have to convince you to try connecting to a malicious server.

Anecdotally, every machine I've RDP'ed to has prompted me with this [0] warning on first connection. Instructions from IT were to just click through the warning. How the hell am I supposed to vet that I'm actually connecting to the right server in that case?

[0] https://techcommunity.microsoft.com/t5/image/serverpage/imag...

Not being a windows person, can you explain what that error means?

RDP connections are distributed as .rdp files which can be (but aren't often/ever) signed. If the file isn't signed you get this warning. If you spin up a windows ec2 instance and downlaod the RDP file from AWS, the file isn't signed so you get this warning, for example.

That's not terribly difficult

Yeah I'm worried here, as our support team uses RDP to log into on-prem servers to a huge number of customers. Some have already been hit with ransomware, so clearly have less than ideal IT security.

If one of their servers gets compromised, it would be bad for us.

Granted most RDP sessions happen in a VM due to the VPN needed, but that's not a huge comfort.

This was patched back in Aug. Why are you worried? Does your support team not even install four month old Windows Updates?

Edit: Downvotes why?

Updates frequently ruin your configurations, opt-outs, and even install additional spyware.

Microsoft has sabotaged trust in their updates system.

Maybe some have not updated all their VMs yet. They have 3-4 VMs each due to VPN incompatibility, not all are used as frequent.

I don't think there's even a protocol handler that would start connection without confirmation.

You can offer .rdp files for download and they will automatically open in the app. The app will tell you not to open untrusted files but the warning is not too scary.

It needs to transfer 4GB over the wire first.

It doesn’t actually have to transfer all 4GB, since you’re just spoofing a header to claim that 4GB is available. The actual payload can be much smaller (like a few kB)

I was trying to use this same vuln for information disclosure since it also has an out-of-bounds read due to that lack of validation, but couldn’t get the extra data to be transferred back to the server. Would’ve been a nice way to defeat ASLR if it had worked

With compression that doesn’t have to be a big hurdle.

Nice write up. From my understanding, this sounds like it would be a good secondary attack, if you could hack the server and the RDP server, when the admin RDPs to the machine, you then attack the admins machine. Disaster ensues

The Hyper-V escape seems of particular note - since using Hyper-V for isolation of suspected malware can be compromised via this vuln.

One would hope that security researchers worth their salt would install Windows updates that are 4 months old at this point.

Fair, but also consider that before a researcher is in the "worth their salt" category, they are learning. Hyper-V seems like a reasonable isolation methodology. Same machine may be either unpatched to evaluate malware against a specific patch level, or was deliberately kept offline. So... possible?

More fundamentally, goes to show that it is possible to have an escape like this, over a communication channel which isn't readily obviously so exoloitable. This, beyond the viln itself, seems like a valuable thing.

>Fair, but also consider that before a researcher is in the "worth their salt" category, they are learning.

What part of the learning process is turning off Windows Updates for months on the host machine? That's like saying cutting the brake lines is part of learning to drive. You have to go out of the way to mess things up, not forget or not know to do something.

There are a ton of people who turn off updates because they just don't want to reboot (or just because they're incensed that Microsoft made updates opt-out). I have done multiple root cause analyses responding to incidents that have turned out to be out-of-date admin machines.

We're talking about security researchers here, who should know better. It'd be like EMTs disabling airbags and not wearing seatbelts.

>or just because they're incensed that Microsoft made updates opt-out

This is the mentality of a child. Do security researchers that think it's a good idea to make security updates opt in for end users?

>I have done multiple root cause analyses responding to incidents that have turned out to be out-of-date admin machines

That'd be a fireable offense in many places.

The salty sysadmins will note that Microsoft has a track record of botched patches to things like this, with effects ranging from not-remediated to majorly breaking other OS components

Do we think this is the only vulnerability of this type in the RDP codebase now that this new attack vector has been found?

There was apparently also a similar vulnerability that someone else recently found in smart card redirection https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-at...

RDP is a protocol, not a code base. It says so in the name.

The comment you are replying to is clearly referring to the codebase containing Microsoft's implementation of RDP.

RDP = "Remote Desktop Protocol "

This lets you view and control a full desktop session (rather than a text command shell) over a network connection to a remote client.

Like VNC, but a Microsoft proprietary protocol.

(I think VNC came into common usage after RDP was a thing, but I'm not certain.)

RDP was first available in NT4 Terminal Services edition, which Wikipedia tells me was released in 1998 - though I think it's fair to say that it became far more popular when Windows 2000 dropped.

VNC was first created by the Oracle and Olivetti Research Lab, Cambridge, prior to their acquisition in 1999. RealVNC (the first version I remember using (I think on an Acorn)) was founded as a company in 2002, TightVNC first released 2001. From memory I was convinced VNC was around much earlier, though Wikipedia set me straight.

For remote desktop use, it seems unfair to mention Xorg. The X windowing system was designed from day 1 as "an architecture-independent system for remote graphical user interfaces and input device capabilities." and version 11 (X11), was first specified in 1987 and is still in common use today. Its also worth mentioning that the implementation and resulting usability /usecases of remote X applications has caused its fair share of conversation and consternation over its lifetime.

Desqview/X and friends. Good times.

I attended one of those week long training classes on Distributed COM.. My take on it was it was fiendishly complicated to get type safety out of DCOM. They were going to make it work, but one group of old timers couldn't see any benefit over bare RPC (which grew into the wire protocol for serialization of Java objects)... oy. Then we has message brokers and somewhere in there I just backed slowly into the hedges and disappeared.

You could switch to a FreeRDP based client to avoid this, although it has had many CVEs before too.

https://www.freerdp.com/ https://github.com/FreeRDP/FreeRDP/security/advisories/ https://security-tracker.debian.org/tracker/source-package/f...

You can also avoid this by being fully-updated, as this was patched back in August: https://msrc.microsoft.com/update-guide/en-US/vulnerability/...

Or mRemoteNG, or Remmina. There are a lot of open source RDP clients out there that are much easier to use for sysadmins than the standard Windows one.

Remmina uses FreeRDP, not sure about mRemoteNG though.

One other point not mentioned, is copying 4GiB of data across a network does take a bit of time, over the internet even longer. This link https://releases.ubuntu.com/21.10/ubuntu-21.10-desktop-amd64... is to a 2.9GB file so you can see how long it will take to download 4GiB over your internet connection.

There is also the point on ASLR making life difficult, well if ASLR is switched on, there are a number of other options which may be also switched on in that part of the system, eg Control Flow Guard, DEP (been around for a couple of decades now), forced ASLR, bottoms up ASLR, High Entropy (more useful if you have shed loads of ram installed than minimum amounts), SEHOP (http://www.uninformed.org/?v=5&a=2&t=txt) and Validate Heap integrity which are all on by default now a days in the systems I have seen. Then there is group policy where in Pro or above, you can control what programs run, in home you can add some of the group policy reg keys and get the same functionality when the functionality exists in the dll's.

It reminds me of the bug where you could use notepad to pop a shell, but I'd be interested to see if this would still work with core isolation switched on, Defender Application Guard switched on to sandbox different apps, not just Edge.

The number of installers for various apps which dont handle Ransomware Protection aka Controlled Folder Access being switched on, even some big names like Dell's Data Vault havent got that sorted yet, but I still think the best way to hack a system is the old way and get them to download and install an app which can run malicious software or become malicious like exploiting macro functionality because who even configures their firewalls to block anything by default from leaving your machine or network or router? Its such a pain configuring that side of things, exploiting human behaviour aka laziness is something you can count on.

Its worth reminding ourselves about Stuxnet, they still havent caught those people, but lots of assumptions exist. https://www.youtube.com/watch?v=Fqk_VUMzY_M https://www.youtube.com/watch?v=DDH4m6M-ZIU https://www.youtube.com/watch?v=CS01Hmjv1pQ

Its sheer size meant AV companies spent over a year reverse engineering it to find out if it was even a virus! Not something a lowly individual could do, but a team of crack coders might.

And a little reminder, when is a false positive not a false positive? https://www.theguardian.com/technology/2014/may/06/antivirus...

> Its worth reminding ourselves about Stuxnet, they still havent caught those people, but lots of assumptions exist. https://www.youtube.com/watch?v=Fqk_VUMzY_M https://www.youtube.com/watch?v=DDH4m6M-ZIU https://www.youtube.com/watch?v=CS01Hmjv1pQ

I thought it was widely known that stuxnet is very likely if not certainly a join NSA and Israel operation.

I know the rumours, but I'm also aware that the US & Israel couldnt admit it was them if it was, plus they cant prove they didnt do it, so it becomes a dead end that is in the public domain.

RDP is Ransomware Deployment Protocol. nuff said

Reply on news.ycombinator.com