Hacker News Reader

Comment by tex0 | Hacker News Reader

Someone should tell them that any system that it logging user supplied data can be affected.

Not only "user facing" systems. Not even a WAF can protect these.

Sadly every WAF vendor is falling over themselves to claim otherwise. I've already had arguments with senior leadership suggesting there's no need to worry about patching because multiple vendors have promised their solutions are better.

The further I get into security the more embarrassed I am for some of the offerings.

I work as a software engineer in cybersecurity.

> embarrassed... for some of the offerings

Welcome to the club.

I am half convinced you can build a successful cyber security business putting a box in a network that does absolutely nothing. I think there's a requirement to at least show a blinking led and have a, not necessarily patched, cable plugged in. But that's about it.

My thinking is, that if you show a cool enough interface (not connected to the box), with lots of widgets and stats, and they don't detect a hack in the time span of 2 years, you can probably walk away with pretty penny! If they do get hacked, just pretend you technically _did_ see the alert, but a junior employee on your side failed to act on it. Sack them, and then re-hire them later. They are the 'fall' person whose job is basically getting fired. Give your customer a discount and try to stay on for 2 more years!

You pretty much can:

> Case in point: the Air Gap. Levy set up a website showcasing a magic amulet of his own creation. Like many cyber defences, his piece of hardware promised to defend against all known and unknown viruses, and stop zero day exploits. His product? An empty box with a blue blinking light on it. Levy had to take his website offline when he started getting sales enquiries by email.

https://www.wired.co.uk/article/ian-levy-national-centre-cyb...

That's pretty much what I've experienced myself at one point.

We had a client sending extremely sensitive data around by email. One day I was told we should all relax, the problem had been solved. You see he'd been sold a PGP hardware appliance.

As the person running the mail system, I could attest that mail wasn't flowing through it. It was literally in a rack. I don't even think it was given an IP address on their actual network. Multiple auditors came in to review the safety of the sensitive data that we had. They were all shown pictures of the rack with the PGP appliance in it, and that always was considered sufficient.

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

This comes to mind

http://audiophile.rocks/index.html

I once saw a spray for CDs that would "absorb stray laser light" or something like that. The bit that gets me is that according to the instructions you're supposed to spray it only on the label side of the disc.

https://en.wikipedia.org/wiki/Magic_Alex

Gold plated audio cables come to mind.

I'm sure you would make money, though the law might catch up with you eventually. A similar tale:

https://www.bbc.com/news/uk-29459896

If the WAF blocks any request containing "{", that would be fairly safe, right?

Yes, some attacks could still get through (e.g. a backend that receives requests base64-encoded), but that's the case generally with WAFs I think.

Thag would also mean blocking any apis that use json. This would not end well in the short term, or long term.

You could probably write a more advanced check than just "{" that would let most JSON through while still blocking the attack.

The devil is in the details. As a random example, you might have a process where all the pre-WAF requests (or explicitly the requests blocked by WAF) get forwarded to a log analysis system that itself uses log4j and is vulnerable, allowing the attacker to gain RCE in your monitoring infrastructure.

Also, blocking any request containing "{" is tricky - like, that's so generic that it's time-consuming to verify that it won't break anything, and it's very likely that JSON is used somewhere in that application traffic, so you can't simply do that.

You could also have a log analysis system that displays logs in the browser and has an XSS vulnerability. So that bypass isn't unique to log4j.

> JSON

You could probably write a more advanced check than just "{" that would let most JSON through while still blocking the attack.

Cloudflare did something along these lines:

https://blog.cloudflare.com/how-cloudflare-security-responde...

Reply on news.ycombinator.com