| |
| ▲ | kiitos 3 days ago | parent | next [-] | | the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2 ok, maybe there is some browser cache issue, whatever, so you trigger your password manager to provide your auth to the website -- but here, every single password manager would immediately notice that the domain in the browser does not match the domain associated with the auth creds, and either refuse to paste the creds thru, or at an absolute minimum throw up a big honkin' alert that something is amiss, which you'd need to explicitly click an "ignore" button to get past. red flag 3 nobody should be able to publish new versions of widely-used software without some kind of manual review/oversight in the first place, but even ignoring that, if someone does have that power, and they get pwned by an attack like this, with at least 3 clear red flags that they would need to have explicitly ignored/bypassed, then CLEARLY this person cannot keep their current position of authority | | |
| ▲ | junon 3 days ago | parent [-] | | > the link in the email went to an obviously invalid domain, hovering the mouse cursor over the link in the email would have made this immediately clear, so even clicking that link should have never happened in the first place. red flag 1 The link went to the same domain as the From address. The URL scheme was 1:1 identical to the real npm's. > but, ok, you click the link, you get a new tab, and you're asked to fill in your auth credentials. but why? you should already be logged in to that service in your default browser, no? red flag 2 Why wouldn't I be? I don't stay logged into npm at all. | | |
| ▲ | kiitos 2 days ago | parent [-] | | huh? the from: address in every email is an arbitrary and unverified text string that the sender provides, anyone can send an email to anyone else and specify a from: president@whitehouse.gov and that's how it will show up to the recipient what do you mean by the URL scheme? a URL scheme is the http or https part of it? and for sure the host part of the URL was not the same as the real npm's host part of their URL? i'm not sure what this comment is trying to accomplish, it parses as FUD | | |
| ▲ | junon 2 days ago | parent [-] | | > the from: address in every email is an arbitrary and unverified text string that the sender provides DKIM et al came back clean. As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1. | | |
| ▲ | kiitos 2 days ago | parent [-] | | how did you evaluate the sender address via DKIM to get "clean" response? I mean I know there are methods to verify stuff about a received email, DKIM by itself only handles message integrity and not sender details, for that you need to fold in DMARC -- but there are all WILDLY technical details that are certainly not what anyone is gonna do before clicking a link in a message body > As for URL scheme, I mean the format and layout of URLs - because it was an MITM attack, they matched 1:1. "scheme" is a well-defined domain term that refers to the e.g. `https://` part of a URL/URI -- but that aside, I still don't get what you're saying here? what is "format and layout of URLs" and how does that relate to "mitm attack"? to cut to the chase, a malicious email maybe contains a link, to a URL, that a victim can click on. but if that link says it goes to `https://npm.org` then it actually does go to `https://npm.org` and there isn't like any special secret way for an email to hijack or mitm that domain or URL resolution. if the link is actually `https://npn.org` then that's a totally different thing, it's not a mitm attack, there is no concept of "format or layout" of that totally different URL "matching 1:1" with `https://npm.org` -- unless you're talking about something totally different to what I'm understanding? edit: wait are we talking about an email sent from a domain `npmjs.help`? DKIM and DMARC and URL scheme validation don't even enter the picture here, this was no kind of mitm attack by any definition -- "npmjs.help" is clear-as-day a malicious domain, and any email from it a clear-as-day phishing attempt.. ! it's fine, we're all human and etc. but it just underscores the issue here being minimizing blast radius of failures, and not anything related to any specific user/human | | |
| ▲ | junon a day ago | parent [-] | | I think you are missing a lot of information I've posted elsewhere in this thread and the original HN post. I didn't minimize anything; I would hope most agree that if anything I've maximized the message as much as I possibly could to prevent further damage. 1. My email client does the validation of certain integrity and security checks and shows a checkmark next to senders that pass. Since npmjs.help was a domain legitimately owned by the attackers, it passed. 2. The link in the email lead to their site at the same domain, most likely performing a MITM between my browser and npm's official servers. 3. You're arguing semantics about "scheme". Please try to understand what I'm attempting to convey: The URLs appeared to match the official npm's site. There was no <a href> trickery. Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains. 4. Emails themselves are not MITM attacks, no. I didn't respond to an email with my credentials. I would never do that. But that isn't what I've ever claimed to have happened. 5. The URLs being similar or identical to npm's isn't how they technically achieved the MITM. The URLs being similar was to avoid arousing suspicion. Hopefully that's explanatory enough. | | |
| ▲ | kiitos 17 hours ago | parent [-] | | > The URLs appeared to match the official npm's site. The domain "npmjs.help" is pretty clearly malicious at a glance, just from the ".help" TLD alone, but yeah as you say > Once I had it in my head (erroneously) that .help was fine, nothing else about the attack stood out as suspicious when it came to the URL or domains. well except that presumably you clicked on a npmjs.help link and the new tab ended up at npmjs.com? but yeah it's a tough break, don't mean to needle you, hopefully learning experience |
|
|
|
|
|
| |
| ▲ | 4 days ago | parent | prev [-] | | [deleted] |
|
