Yikes… i guess i am confused though. What data was being sent through this channel? What did they get from people while it happened and why did it take 2 months past them stopping it to finally make a release? I love the app, but this sounds really bad.
The software itself, and the devs, have little to nothing to do with this besides detecting the issue. Which was not obvious, since (it seems) the attack was targeted at specific IPs/hosts/places. It likely worked transparently without alteration for most users, probably including the devs themselves.
It also would only affects updates through the built-in updater; if you disabled that, and/or installed through some package managers, you would not have been affected.
A disturbing situation indeed. I assume some update regarding having adequately digitally signed updates were done (at least, I hope… I don’t really use N++ anymore). But the reality is, some central infrastructure are vulnerable to people with a lot of resources, and actually plugging those holes requires a bit of involvement from the users, depending how far one would go. Even if everything’s signed, you have to either know the signatory’s public key beforehand or get a certificate that you trust. And that trust is derived from an authority you trust (either automatically through common CA lists, or because you manually added it to your system). And these authorities themselves can become a weak point when a state actor butts in, meaning the only good solution is double checking those certificates with the actual source, and actually blocking everything when they change, which is somewhat tedious… and so on and so on.
Of course, some people do that; when security matters a LOT. But for most people, basic measures should be enough… usually.
From my understanding: Basically the attackers could reply to your version check request (usually done automatically) and tell N++ that there were a new version available. If you then approved the update dialogue, N++ would download and execute the binary from the update link that the server sent you. But this didn’t necessarily need to be a real update, it could have been any binary since neither the answer to the update check nor the download link were verified by N++
Expanding on this: the exploit was against their domain name, redirecting selected update requests away from the notepad++ servers. The software itself didn’t validate that the domain actually points to notepad++ servers, and the notepad++ update servers would not see any information that would tell them what was happening.
Likely they picked some specific developers with a known public IP, and only used this to inject those specific people with malware.
That’s what they say they rolled out, after: “Within Notepad++ itself, WinGup (the updater) was enhanced in v8.8.9 to verify both the certificate and the signature of the downloaded installer”
The previous release already fixed this, or evaded the issue.
The channel was the update mechanism. Upon Notepad++ checking for updates, they were able to inject their own. So if you updated via the apps own update checker they could have misdirected you into installing something else or something modified.
Yikes… i guess i am confused though. What data was being sent through this channel? What did they get from people while it happened and why did it take 2 months past them stopping it to finally make a release? I love the app, but this sounds really bad.
The software itself, and the devs, have little to nothing to do with this besides detecting the issue. Which was not obvious, since (it seems) the attack was targeted at specific IPs/hosts/places. It likely worked transparently without alteration for most users, probably including the devs themselves.
It also would only affects updates through the built-in updater; if you disabled that, and/or installed through some package managers, you would not have been affected.
A disturbing situation indeed. I assume some update regarding having adequately digitally signed updates were done (at least, I hope… I don’t really use N++ anymore). But the reality is, some central infrastructure are vulnerable to people with a lot of resources, and actually plugging those holes requires a bit of involvement from the users, depending how far one would go. Even if everything’s signed, you have to either know the signatory’s public key beforehand or get a certificate that you trust. And that trust is derived from an authority you trust (either automatically through common CA lists, or because you manually added it to your system). And these authorities themselves can become a weak point when a state actor butts in, meaning the only good solution is double checking those certificates with the actual source, and actually blocking everything when they change, which is somewhat tedious… and so on and so on.
Of course, some people do that; when security matters a LOT. But for most people, basic measures should be enough… usually.
From my understanding: Basically the attackers could reply to your version check request (usually done automatically) and tell N++ that there were a new version available. If you then approved the update dialogue, N++ would download and execute the binary from the update link that the server sent you. But this didn’t necessarily need to be a real update, it could have been any binary since neither the answer to the update check nor the download link were verified by N++
Thats what i was thinking, but there is no mention on if this did happen and if it did what was compromised or allowed to happen.
How would n++ devs know?
Expanding on this: the exploit was against their domain name, redirecting selected update requests away from the notepad++ servers. The software itself didn’t validate that the domain actually points to notepad++ servers, and the notepad++ update servers would not see any information that would tell them what was happening.
Likely they picked some specific developers with a known public IP, and only used this to inject those specific people with malware.
So the solution would have been an SSL certificate check on the client side.
That’s what they say they rolled out, after: “Within Notepad++ itself, WinGup (the updater) was enhanced in v8.8.9 to verify both the certificate and the signature of the downloaded installer”
Can’t tell if that would have helped
They could have just piped the binaries though the same server since they had this level of access. They would have had months to figure it out.
Oof, I thought it was just a DNS hijack. If they had access to the server, it’s game over regardless.
It’s not game over regardless if the updater checks a signature of the update installer. Them it wouldn’t run an installer by someone else.
The previous release already fixed this, or evaded the issue.
The channel was the update mechanism. Upon Notepad++ checking for updates, they were able to inject their own. So if you updated via the apps own update checker they could have misdirected you into installing something else or something modified.