Cloudflare

4 Articles

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

May 13, 2022 by 7 Comments

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned” →

Run Your Own Server For Fun (and Zero Profit)

March 15, 2022 by 126 Comments

It seems there’s a service for everything, but sometimes you simply learn more by doing it yourself. If you haven’t enjoyed the somewhat anachronistic pleasures of running your own server and hosting your own darn website, well, today you’re in luck!

Yes, we’re going to take an old computer of some sort and turn it into a web server for hosting all of your projects at home. You could just as easily use a Raspberry Pi –even a Zero W would work — or really anything that’ll run Linux, but be aware that not all computing platforms are created equally as we’ll discuss shortly.

Yes, we’re going to roll our own in this article series. There are a lot of moving parts, so we’re going to have to cover a lot of material. Don’t worry- it’s not incredibly complicated. And you don’t have to do things the way we say. There’s flexibility at every turn, and you’re encouraged to forge your own path. That’s part of the fun!

Note: For the sake of space we’re going to skip over some of the most basic details such as installing Linux and focus on those that have the greatest impact on the project. This article gives a high level overview of what it takes to host your project website at home. It intentionally glosses over the deeper details and makes some necessary assumptions.

Continue reading “Run Your Own Server For Fun (and Zero Profit)” →

The Grooviest Random Number Generator Ever

January 4, 2018 by 28 Comments

Cloudflare is one of those Internet companies you use all the time, but don’t usually know it. Big websites you visit use Cloudflare to shore up their defenses against denial of service attacks. The company needed some truly random numbers for its security solutions, so it turned to some groovy old tech: lava lamps. In their office is a wall of 100 lava lamps monitored by cameras. The reaction of the lamps is unpredictable, and this allows them to generate really random numbers. [Joshua], a Cloudflare employee, talks about the technical details of the system in a recent blog post.

You might think this is a new and novel idea, but it turns out the LavaRnd (or maybe it is LavaRand — there’s some dispute if you read the comments below) system has been around for a while. In fact, we covered it way back in 2005. Silicon Graphics patented the system in 1996.

Continue reading “The Grooviest Random Number Generator Ever” →

Cloudbleed — Your Credentials Cached In Search Engines

February 24, 2017 by 25 Comments

In case you are still wondering about the SHA-1 being broken and if someone is going to be spending hundreds of thousands of dollars to create a fake Certificate Authority and sniff your OkCupid credentials, don’t worry. Why spend so much money when your credentials are being cached by search engines?… Wait, what?

A serious combination of bugs, dubbed Cloudbleed by [Tavis Ormandy], lead to uninitialized memory being present in the response generated by the reverse proxies and leaked to the requester. Since these reverse proxies are shared between Cloudflare clients, this makes the problem even worst, since random data from random clients was leaking. It’s sort of like Heartbleed for HTTP requests. The seriousness of the issue can be fully appreciated in [Tavis] words:

“The examples we’re finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to cleanup. I’ve informed cloudflare what I’m working on. I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.”

sexAccording to Cloudflare, the leakage can include HTTP headers, chunks of POST data (perhaps containing passwords), JSON for API calls, URI parameters, cookies and other sensitive information used for authentication (such as API keys and OAuth tokens). An HTTP request to a Cloudflare web site that was vulnerable could reveal information from other unrelated Cloudflare sites.

Adding to this problem, search engines and any other bot that roams free on the Internet, could have randomly downloaded this data. Cloudflare released a detailed incident report explaining all the technicalities of what happened and how they fixed it. It was a very quick incident response with initial mitigation in under 47 minutes. The deployment of the fix was also quite fast. Still, while reading the report, a sense that Cloudflare downplayed this issue remains. According to Cloudflare, the earliest date that this problem could have started is 2016-09-22 and the leak went on until 2017-02-18, five months, give or take.

Just to reassure the readers and not be alarmist, there is no evidence of anyone having exploiting what happened. Before public exposure, Cloudflare worked in proximity with search engines companies to ensure memory was scrubbed from search engine caches from a list of 161 domains they had identified. They also report that Cloudflare has searched the web (!), in sites like Pastebin, for signs of leaks and found none.

On the other hand, it might be very well impossible to know for sure if anyone has a chunk of this data cached away somewhere in the aether. It’s impossible to know. What we would really like to know is: does [Tavis] get the t-shirt or not?