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

We have a year to fix security everywhere

jyn.dev

Post reply on HN
Print view View original

41–50 of 372 posts

Re: We have a year to fix security everywhere

#41

Post by Gigachad »

pmlnr wrote: post #8

Here's an idea: as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports. As an example: WordPress is a horrible thing, but the core has been through so much, that it's suprisingly secure. Then plugins and themes come, and whoosh, the security is gone. We need a new KISS: keep it simple, stupid, secure.

This is not at all easy though. Most Wordpress users are not software companies. They contract some work out to set it up, maybe some recurring maintenance but they don’t have in house development experience.

If they have a site existing today built on plugins and a theme, how are they realistically going to simplify this? How would they even know they need to without the site being hacked?

Re: We have a year to fix security everywhere

#42

Post by mc3301 »

simonw wrote: post #5

I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.

I've ran simple prompts such as "Do a in-depth sweep of this (private) repo and find any security flaws" for a few dozen long-running apps and websites that I have access to. Every single one came back with multiple real vulnerabilities within 5 or 10 minutes.

Re: We have a year to fix security everywhere

#43

Post by Cthulhu_ »

pmlnr wrote: post #8

Here's an idea: as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports. As an example: WordPress is a horrible thing, but the core has been through so much, that it's suprisingly secure. Then plugins and themes come, and whoosh, the security is gone. We need a new KISS: keep it simple, stupid, secure.

> as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports.

We've been trying that for years but the enthusiasm of developers and the eagerness of their employers fight against it. Worse, with coding LLMs it's now easier than ever to output a lot of code, fast.

It'll ultimately be up to more experienced developers to salvage these projects. Or not, given that the coding LLMs aren't stopping and will likely get better over time. Either way, we will need experienced people that know what to look out for / know how to instruct LLMs to output secure code and find weaknesses etc.

Re: We have a year to fix security everywhere

#44

Post by hnsr »

simonw wrote: post #5

I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.

Can confirm.

I work at an e-commerce agency where we work with (among others) Adobe Commerce.

The number of unauthorized RCE vulnerabilities being reported not only in the core product, but also very popular modules used in the community[1] is going through the roof.

And we are having a lot of close calls, too; just last weekend, a 0day[2] was widely being exploited at a large scale, before any publication or patch. We have learnt to be on the ball with applying patches and security updates, and even with all that effort, we saw a few projects already being hit by the initial log poisoning. We got lucky that nothing was fully compromised but I am sure that many, many webshops got infected last weekend. And not even a day later there are already other variants of this exploit showing up.

[1] https://sansec.io/research/amasty-mass-disclosure

[2] https://sansec.io/research/stylesmuggler-0day

Re: We have a year to fix security everywhere

#45

Post by Cthulhu_ »

Gigachad wrote: post #31
simonw wrote: post #5

I don't think we even have a year. The current batch of LLMs are ferociously good at identifying vulnerabilities.

Thankfully we have already made good progress towards things like arm memory tagging and memory safe languages. It’s a rocky period right now but the future will be much more secure after all the low hanging fruit are found.

That's definitely an improvement, but it's just one aspect of cybersecurity. Logical errors allowing people to e.g. log into services and extract data are likely everywhere still.

Re: We have a year to fix security everywhere

#46

Post by tgv »

Gigachad wrote: post #34
LoganDark wrote: post #13

It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely. People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons,…

That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.

Still, it doesn't have to ping back, and ssh can (should) be very restrictive.

Re: We have a year to fix security everywhere

#47

Post by rukuu001 »

taurath wrote: post #21
protocolture wrote: post #20

Just like Cryptolocker, this will be the "Finding Out" phase for everyone who has been putting off best practice security. But, lets be clear, Best Practice will save you. We can engineer assuming there are zero days in path. Go to your CTO now cap in hand and ask for overlapping controls, wafs, application monitoring, backups and all the other shit you haven't been doing. Because when you find out, I will laugh, it…

Meanwhile a huge portion of management and leadership in software companies are encouraging everyone to de facto stop looking at code and let the LLM and a bunch of boundaries handle this for you.

A couple high-profile crash & burns will get their attention.

Re: We have a year to fix security everywhere

#48

Post by hypfer »

Gigachad wrote: post #34
LoganDark wrote: post #13

It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely. People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons,…

That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.

Sure, but still, attack surface could and should be minimized by rethinking what exactly even needs to be on a server the general public can use.

There are a lot of security problems you can categorically rule out by simply not involving a cloud. Clouds have been involved in a lot of things, because everyone was doing it, and because that's how you can collect rent, but they aren't really necessary for most use-cases.

So we could definitely get the exposure down there. We'd just have to fundamentally shift the defaults of this industry.

Re: We have a year to fix security everywhere

#49

Post by bob1029 »

pmlnr wrote: post #8

Here's an idea: as a first step, simplify everything, and make sure you're aware how your stack works, and what it imports. As an example: WordPress is a horrible thing, but the core has been through so much, that it's suprisingly secure. Then plugins and themes come, and whoosh, the security is gone. We need a new KISS: keep it simple, stupid, secure.

Minimization of 3rd party dependencies has always been a key for risk reduction. Now more than ever before.

Some stacks make this a lot easier than others. I regret the rules of HN effectively forbid this conversation because it has meaningful technical consequences and isn't purely about ideological flame war.

Re: We have a year to fix security everywhere

#50

Post by jsiepkes »

Gigachad wrote: post #34
LoganDark wrote: post #13

It's just the same advice as ever: be extremely, exceedingly careful in what you expose to any network. When I set up machines for production, they don't respond to pings and they don't even have an SSH port open without knocking. There are also ways to eschew the need for an SSH port entirely. People who never took that seriously will never take this seriously either, and that's their loss. (And loss of the commons,…

That’s fine for your home server, but if you want an actual server that the general public can use, it has to be exposed to the internet.

But not everything needs to be directly exposed to the internet. Framework had their data leaked because their metabase instance was hacked with a zero-day. Why was it directly exposed to the Internet? Why not require the use of a VPN like a Wireguard based solution or Nebula for these "internal" kind of apps?
Post reply on HN