Cybersecurity

5922 readers

241 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Be respectful. Everyone should feel welcome here.
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
No Ads / Spamming.
No pornography.

Community Rules

Idk, keep it semi-professional?
Nothing illegal. We're all ethical here.
Rules will be added/redefined as necessary.

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected]

Notable mention to [email protected]

founded 2 years ago

MODERATORS

kid

[email protected]

BreakingWAF: Widespread WAF Bypass Impacts Nearly 40% of Fortune 100 companies (www.zafran.io)

submitted 1 month ago by kid to c/cybersecurity

5 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 1 month ago* (last edited 1 month ago) (2 children)

I feel like this doesn't explain a lot. What makes it so trivial to find the origin? They just brush it aside as easy.

Also this really just comes back to: secure your origins folks, especially if you're relying on edge security features. Nobody should be relying on a waf though.

[–] [email protected] 5 points 1 month ago (1 children)

The tech blog is much better: https://www.zafran.io/resources/breaking-waf-technical-analysis

It boils down to scanning all IPV4 space, and grabbing the SSL certificate returned by any webservers on port 443. If the server is incorrectly configured the fields in the SSL cert will tell you what domains it serves. And using Certificate Transparency logs to figure out what domains you want to target. I wouldn't really call this a flaw that breaks anything. It's just a byproduct of how SSL, IPV4, and WAFs work.

[–] [email protected] 4 points 1 month ago (1 children)

Ahh that makes more sense, especially if people aren't using the cf origin certs. I'd expect SNI to prevent this on newer systems though, unless it's the default cert on the ip.

[–] [email protected] 4 points 1 month ago

From the article:

The TLS-SNI header is used by CDN servers to route requests based on the Server Name in the header. However, a typical front end server, or even a load balancer (LB), belongs to a single app or organization, and does not typically need to handle the SNI header. The easy and reasonable way to configure TLS certificates on such a server, is to either:  Serve all requests with a single TLS certificate that has SANs (Subject Alternative Names) for all the domains that are used Have multiple certificates, chosen according to SNI, with one of them as the default. In both of these common cases, sending a HTTPS request directly to the IP of a front end server, without any SNI, will present us with a default server certificate. This certificate will reveal what domains are being served by this server.

So apparently the real issue is that people aren't using SNI correctly.

[–] [email protected] 4 points 1 month ago

This means that when a CDN service is used as a WAF, the web application it protects is open to Internet traffic, and is expected to validate that it responds only to web traffic that originates from and by the CDN service.

When this validation is lacking, backend applications can easily be directly accessed over the Internet.

So, misconfigured backends that don't limit access to CDN sources can be fingerprinted through web scans. Seems like a big honking nothing-burger.