Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We all dodged a bullet

xeiaso.net

Post reply on HN
Print view View original

261–270 of 498 posts

Re: We all dodged a bullet

#261

Post by bunderbunder »

Groxx wrote: post #225
bunderbunder wrote: post #214

Earlier quoted context omitted.

C has a lot of characteristics beyond simple lack of a standard automatic package manager that complicate the situation. The more interesting comparison to me is, for example, my experience on C# projects that do and do not use NuGet. Or even the overall C# ecosystem before and after NuGet got popular. Because then you're getting closer to just comparing life with and without a package manager, without all the extra…

when I was doing C# pre-nuget we had an utterly absurd amount of libraries that nobody had checked and nobody ever upgraded. so... yeah I think it applies there too, at least from my experience. I do agree that C is an especially-bad case for additional reasons though, yeah.

Gotcha. When I was, we actively curated our dependencies and maintaining them was a regularly scheduled task that one team member in particular was in charge of making sure got done.

Re: We all dodged a bullet

#262

Post by kiitos »

nalllar wrote: post #71
cataflam wrote: post #35

Besides the ecosystem issues, for the phishing part, I'll repost what I responded somewhere in the other related post, for awareness --- I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enou…

> 1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try. Sites choosing to replace password login with initiating the login process and then clicking a "magic link" in your email client is awful for developing good habits here, or for giving good general advice. :c

how is this any worse than a spear phishing email that gives a login link to a malicious domain that looks the same as the official domain?

Re: We all dodged a bullet

#263

Post by ornornor »

cyphar wrote: post #128
simoncion wrote: post #81

Earlier quoted context omitted.

> These companies tell customers to be suspicious of phishing attempts, and then they pull these stunts. Yep. At every BigCo I've worked at, nearly all of the emails from Corporate have been indistinguishable from phishing. Sometimes, they're actual spam! Do the executives and directors responsible for sending these messages care? No. They never do, and get super defensive and self-righteous when you show them exactl…

A few years ago our annual corporate phishing training was initiated by an email sent from a random address asking us to log in with our internal credentials on a random website. A week later some executive pushing the training emailed the entire company saying that it was unacceptable that nobody from engineering had logged into the training site and spun some story about regulatory requirements. After lots of back…

It’s all just box ticking and CYA compliance.

“We got pwned but the entire company went through a certified phishing awareness program and we have a DPI firewall. Nothing more we could have done, we’re not liable.”

Re: We all dodged a bullet

#264

Post by dghlsakjg »

MichaelZuo wrote: post #253
dghlsakjg wrote: post #227

Earlier quoted context omitted.

What about this sounds sensible? I have already documented, in writing, in multiple places, that the automated software has raised a false alarm, as well as providing a piece of code demonstrating that the alert was wrong. They are asking me to document it in an additional place that I don't have access to, presumably for perceived security reasons? We already accept that my reasoning around the false alarm is valid,…

If your sufficiently confident there can be no negative consequences whatsoever… then just email that person’s superiors and cc your superiors to guarantee in writing you’ll take responsibility? The ops person obviously can’t do that on your behalf, at least not in any kind of organizational setup I’ve heard of.

As the developer in charge of looking at security alerts for this code base, I already am responsible, which is why I submitted the exemption request in the first place. As it is, this alert has been active for months and no one from security has asked about the alert, just my exemption request, so clearly the actual fix (disregarding or code changes) are less important than the process and alert itself.

So the solution to an illogical, kafkaesque security process is to bypass the process entirely via authority?

You are making my argument for me.

This is exactly why people don’t take security processes seriously, and fight efforts to add more security processes.

Re: We all dodged a bullet

#265

Post by [deleted] »

anon7000 wrote: post #31

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated. This happened even if you had pinned dependenc…

[deleted]

Re: We all dodged a bullet

#267

Post by gcau »

Zak wrote: post #231

> If you were targeted with such a phishing attack, you'd fall for it too and it's a matter of when not if. Anyone who claims they wouldn't is wrong. I like to think I wouldn't. I don't put credentials into links from emails that I didn't trigger right then (e.g. password reset emails). That's a security skill everyone should be practicing in 2025.

"'such' a phishing attack" makes it sound like a sophisticated, indepth attack, when in reality it's a developer yet again falling for a phishing email that even Sally from finance wouldn't fall for, and although anyone can make mistakes, there is such a thing as negligent, amateur mistakes. It's astonishing to me.

Re: We all dodged a bullet

#268

Post by superkuh »

Wow! This site uses anubis with the meta-refreshed based challenge that doesn't require javascript. So I can actually read the article in my old browser. It's so rare for anubis deployals to be setup with any configuration beyond the defaults. What a delight.

Re: We all dodged a bullet

#269

Post by Roguelazer »

Dilettante_ wrote: post #7
loloquwowndueo wrote: post #4

Earlier quoted context omitted.

Should be - open another browser window and manually log into npm whatever, and update your 2fa there. Definitely good practice .

This is the Way. To minimize attack surface, the senders of authentic messages should straight-up avoid putting links to "do the thing" in the message. Just tell the user to update their credentials via the website.

For most users, that'll just result in them going to Google, searching for the name of your business, and then clicking the first link blindly. At that point you're trusting that there's no malicious actors squatting on your business name's keyword -- and if you're at all an interesting target, there's definitely malvertising targeting you.

The only real solution is to have domain-bound identities like passkeys.

Re: We all dodged a bullet

#270

Post by kiitos »

zaphar wrote: post #41
SirFatty wrote: post #21

It's typical phishing email... and if the author when though any type of cybersecurity training, they would see that the email wasn't that great. The sense of urgency is always the red flag.

I go through those trainings several times a year. That email is as close to perfect for a phishing email as I've ever seen.

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

Post reply on HN