Notepad++ Hijacked by State-Sponsored Hackers
118 points by eranb
118 points by eranb
With these changes and reinforcements, I believe the situation has been fully resolved. Fingers crossed.
What?
Total amateur show. Also see the comment in the blog post linked above (https://doublepulsar.com/small-numbers-of-notepad-users-reporting-security-woes-371d7a3fd2d9):
1995 here and I would like to introduce to you the concept of path traversal - this "fix" only restricts to downloading malicious payloads from github.com. e.g. https://github.com/notepad-plus-plus/notepad-plus-plus/../../gbiagomba/Naughty_Tarbawlz/raw/refs/heads/main/EICAR_Testfiles/eicar.com would pass the new URL prefix check
I just checked and it's still implemented this way. I love Notepad++ but it is now clear that it's dangerous to use this tool.
I feel like that's always been the vibe with these community-loved tools. Most of them don't pay much mind if any to infosec/opsec.
Maybe the fact that their communication is honest is part of why they are loved. Perfect absolute flawless security does not exist, despite what $ANYCORP could claim.
Sure, but "oopsy, I didn't care about your security! tee-hee!" is both honest and should be disqualifying. I know that's not what happened here, but it is common to see breaches and everyone shrugs if they aren't personally affected if the tool falls into this "beloved" status (a certain games store comes to mind).
I can't believe a well funded company with multiple highly paid application and infrastructure security experts isn't able to provide more robust guarantees than this.
This is absolutely bonkers. I guess the only defense I had against this (running Notepad++ on all my devices) is that I am too unimportant to be targeted.
But the post is extremely thin on details. What kind of exploit was being shipped to targeted users? How can I check if I'm affected?
I'll save others a click to a Medium site:
I’ve only talked to a small number of victims. They are orgs with interests in East Asia. Activity appears very targeted. Victims report hands on keyboard recon activity, with activity starting around two months ago.
It has just this about the exploit.
I'm assuming that if a victim is skilled enough to recognize "keyboard recon activity" and report it, surely they must've shared the binary with the exploit as well, right? Is anyone analyzing it yet?
What is keyboard revon and howwould I notice it?
From context, I think they mean that there's someone at the other end typing in commands to run on the compromised computer - i.e. the attacker is giving each compromised computer individual attention, rather than an at-scale attack where the exact same malicious thing is done on every computer.
It's recognizable if you have a log of commands executed - the sort of commands you'd see from a human poking around are pretty distinct from what an automated exploitation script would do, and might even include typos and such.
This traffic is supposed to be over HTTPS, however it appears you may be to tamper with the traffic if you sit on the ISP level and TLS intercept. In earlier versions of Notepad++, the traffic was just over HTTP.
Fetching update instructions via HTTP is madness, I wonder up to which version it was done like that. But it seems like at the point where this blog post was written, it wasn't known that Notepad++'s host was compromised and they conjectured the cause to be TLS intercept.
Fetching update instructions via HTTP is madness
It's not automatically a bad idea, as long as you are not concerned about confidentiality and do integrity checking via another mechanism. The FreeBSD pkg tool use HTTP for a long time because the package database was signed with a private key and the individual packages had cryptographic hashes stored stored in the package database, and this made it easy to put a caching proxy in front of the package site for a bunch of machines to share. It moved to HTTPS because a bunch of places had an HTTPS-only policy (which is sensible: mandating HTTPS everywhere is a simpler policy to get right than HTTPS-except-when-you-have-a-good-reason-that-HTTP-is-secure).
But if you're just downloading things and not verifying them, especially executable things, HTTP is a disaster.
Even cases like this with a package database it is pretty complex. For example you need to be very careful that an attacker can't perform an unintentional rollback. This could possibly result in older (signed) packages with vulnerabilities being used (either not upgraded or the packages themselves rolled back).
APT servers used HTTP for a long time for similar reasons.
Still, why would I want anyone near the network path to know which packages I download? That information can reveal a lot.
Honestly I suspect the main reason Debian stopped using HTTP for this is so that people would stop saying "Well, Debian does it, so we can do it too" without realizing that Debian has a whole lot more going on behind the scenes that made it safe in this one case.
Does apt download the updates smoothly enough within a single connection to block size fingerprinting of individual packages?
The path includes the package name & version: http://http.us.debian.org/debian/pool/main/c/curl/curl_8.14.1-2+deb13u2_amd64.deb
If this goes over HTTP, everything is in the open, sure — my question is whether the move to HTTPS hides that information reliably.
That is a good point, there is nuance to it indeed. As you said, if you are not concerned about confidentiality and have another root of trust with which you verify, it's fine.
But if you're just downloading things and not verifying them, especially executable things, HTTP is a disaster.
Yeah.
HTTP was the norm, but as demonstrated here that's kind of moot if the ISP is compromised.
That's why an embedded signature in the file is needed, even when transferred over TLS. Though if an app does adopt that the developers of the app have to assume that by proxy their own system is now being subjected to the same level of attacker scrutiny.
If anyone is curious, dnshistory.org seems to suggest the old hosting provider was Hostinger, up to as late as 2 weeks ago. They've now switched to Aqua Ray which seems less trustworthy, tbh.
This is not meant to be a dig at Hostinger in any way. I think their response was professional (the author seems satisfied with it too?). Getting hacked is a bad look, but we don't know how they got hacked, and since we seem to be dealing with state-sponsored hackers... could've happened to anyone, really.
dealing with state-sponsored hackers... could've happened to anyone, really.
This is really important to stress out IMHO. Cryptography (and cybersecurity in general) is needed and an interesting field (cool maths, what's not to love about it?), but I feel sometimes people have delusion of grandeur about how far one can fight back about state-level actors. When your threat model is intelligence services with next to unlimited resource, it's over before it even starts.
No idea of the scale of these hosting services, but I have noticed a belief that smaller providers are "more trustworthy", but if your concern is attackers at this scale and complexity then hypothetical differences in trustworthiness (esp. ones based primarily on corporation size) is secondary to ability to invest in infra security and hardening.
But also you need to simply start assuming your infra is compromised and verify information is correctly verified through other channels
Something I find interesting with the various attacks is that they're not new techniques at all. Quite often they could be considered fairly basic (TLS interception isn't news). However, we used to consider these threats are not very likely to happen in the open because they're not very stealth.
Fast-forward today and we get news of them every few months or even weeks. Intercepting traffic of everybody using notepad++ to target a limited number of opponents in a specific region to exfiltrate data? No hesitation.
I guess the main change is the proliferation of state-sponsored groups that aren't directly part of these states and offer plausible deniability (or just silence).
We used to consider these threats are not very likely to happen in the open because they're not very stealth.
But the stealthiness of a technique isn't just an inherent trait of its technical means, it's also a measure of monitoring and review in the system it's used against. In its most basic form (I'm not saying this is what happened, it's just the canonical example of this distinction) any threat is 100% stealthy if no one's watching. TLS interception isn't inherently stealthy on its own. But if you only need it to work for a few weeks, and you know no one's going to look for it for a few weeks, you've got yourself an extremely stealthy attack.
Plus, as BenjaminRi pointed out, the stealthiness threshold isn't exactly fixed, either. Realistically, a state actor targeting the infrastructure of a commercial hosting services provider in a foreign country can afford to break a lot of glassware these days. What are the victims going to do?
Plus, as BenjaminRi pointed out, the stealthiness threshold isn't exactly fixed, either. Realistically, a state actor targeting the infrastructure of a commercial hosting services provider in a foreign country can afford to break a lot of glassware these days. What are the victims going to do?
Reverse-engineer the attacker activity and publish technical details online. Once those details are published, the exploits they're using to get in and the tools that they're implanting in the malicious updates become significantly less valuable. Which is problematic if they spent a lot of money building the pieces for the attack.
I think my writing there was imprecise. I agree, there are things victims can do to inconvenience foreign state actors, and while one victim doing that isn't a lot, if everyone gangs up then a history of bad risk/benefit analyses will begin to hurt.
What I meant is that state actors enjoy a quasi-monopoly on violence at home and, past a certain threshold, wide-reaching impunity abroad, so the consequences of being found aren't quite as bad as they are for, say, organised crime. So they don't have an immediate need to outmaneuver law enforcement in all their ops the way organised crime does, and can afford less stealthiness if it's economically feasible. Sure, sometimes they need to, for various reasons (politically sensitive op, burning a zero-day etc.) but the mere fact of an attack being potentially linked to them isn't as big a deal.
Organised crime orgs can get shut down very theatrically from leaving sufficiently easily-followed traces even just one time. I don't think the PLASF is in as bad a pickle if it turns out it really was them. They could literally leave a note saying "hey it was us, greetings from Beijing, kind regards gen. Zhang" and nothing's going to happen, because we simply don't have credible international institutions and channels to deal with that.
I.e. when I said "what are the victims going to do?" I meant it as in, what, is Don Ho (Notepad++'s author) going to call the Internet police on the PLASF?
Organised crime orgs can get shut down very theatrically from leaving sufficiently easily-followed traces even just one time. I don't think the PLASF is in as bad a pickle if it turns out it really was them. They could literally leave a note saying "hey it was us, greetings from Beijing, kind regards gen. Zhang" and nothing's going to happen, because we simply don't have credible international institutions and channels to deal with that.
I.e. when I said "what are the victims going to do?" I meant it as in, what, is Don Ho (Notepad++'s author) going to call the Internet police on the PLASF?
That makes sense. I was pointing out that, even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth. Those reasons are that as their tools and techniques become better known, they become less effective, and they spend money to develop/acquire those tools and techniques. Whether they're zero-day exploits or remote-access toolkit payloads. In this case, the ability to silently infect notepad++ uses was very valuable. Now it's at worst lost and at best less valuable.
[1]: While they may not mind being attributed, I don't think taking credit for their attacks is good for any of them, or a thing we'll likely see; if they admit things beyond a certain scale, retaliation could happen during things like trade negotiations or even imposition of sanctions that will give them much less impunity domestically as their executives deal with those.
I was pointing out that, even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth.
Oh, definitely. It's not just that it makes tools less effective, as you rightly point out, it's also that simply exposing their TTPs can be problematic. No team is infinitely skilled across all the range of offensive and defensive skills. Simply exposing what they're good at tells others what to watch out for, and implicitly communicates what they might not be as good at. A general disregard for stealth is definitely a bad stance, including for the reasons you mentioned in your footnote.
The post I was responding to came from a slightly different position: the technique being used was, itself, unstealthy, though not very sophisticated. The overall calculus is the same, of course -- a state-affiliated actor, like any red team, should aim for not being exposed.
Where I think the difference lays is the weights of the various factors being considered when assessing the risk of exposure. If lack of stealth is inherent in some intrusion method, the decision to greenlight it or not vs. the immediate gains it brings is just made along different lines for state actors, who have some means to protect their operatives, can leverage loyal press to take some flak or redirect public attention and so on. Things that we (as in industry professionals) would write off as too primitive may hold out way better than we expect in risk assessment meetings.
even though these state-affiliated actors have little to fear from attribution for the most part[1], and nearly nothing to fear from international policing, they still have significant reasons to prefer stealth.
They also have significant reasons to keep their powder dry for a case where stealth is absolutely necessary, and every time you use an exploit you risk burning it.
TLS interception isn't news
Is it really that frequent? Last one I remember was the jabber.ru interception, now this. What other examples have I missed?
TLS interception requires the server’s hosting provider to be compromised so that the attacker can perform on-path spoofing of ACME. I haven’t heard that hosting providers are routinely violated in this manner.
I think it's commonplace that it's actually getting difficult to point out specific examples!
The jabber.ru one was probably very targetted and done close to site. Like this one for notepadd++ it seems. I guess these are pretty uncommon, or at least not widely known.
From the other side, i.e. close to clients, you have stuff like https://arstechnica.com/information-technology/2015/01/gogo-issues-fake-https-certificate-to-users-visiting-youtube/ . I'm pretty sure many ISPs were doing it regularly, probably especially more "remote" places, including Australia. It has certainly gotten more difficult and more visible over the years so this case where the intent isn't completely nefarious is likely less common nowadays.
Then you have Amesys and Bluecoat, selling interception boxes for use by corporations. And also selling these to various dictatorships (IIRC respectively Libya and Syria 15 years ago).
Ah I thought you were only talking about MITM attacks against specific servers.
AIUI much of the work on certificate authority compliance and certificate transparency was intended to prevent ISPs from running mass TLS interception. I believe that nowadays it should be impossible for an ISP to MITM its users.
Corporate interception is done with the informed consent of the owners of the client devices so strictly speaking it isn’t an attack. (Tho arguably the users are under some degree of duress and the servers don’t get a choice.)
I feel a bit relieved, at least, because it seems the issue was caused by a vulnerability with the hosting provider.
That statement from the provider is awkward on mobile, with horizontal scrolling.
Dear Customer, We want to further update you following the previous communication with us about your server compromise and further investigation with your incident response team. We discovered the suspicious events in our logs, which indicate that the server (where your application https://notepad-plus-plus.org/update/getDownloadUrl.php was hosted until the 1st of December, 2025) could have been compromised. As a precautionary measure, we immediately transferred all clients’ web hosting subscriptions from this server to a new server and continued our further investigation. Here are the key finding points: