🅭

Closing the open redirect vulnerability in the Libravatar ecosystem

Libravatar is a decentralized open-source alternative to Gravatar – the avatar image service. Last week, I noticed an URL Redirection to Untrusted Site (‘Open Redirect’) vulnerability (CWE-601) in the Libravatar application programming interface (API) specification.

The Libravatar API is used to obtain an avatar image (a profile photo) from someone’s email address. The API is essentially a clone of the Gravatar API, except that the specification is decentralized (like email) instead of relying on a single service provider. Any email domain can add domain name system (DNS) service (SRV) records to designate a specific website as its avatar hosting service.

I was reading up on the Gravatar API and investigated some alternatives when I stumbled upon Libravatar. To my horror, I noticed that both API specifications described an open redirect as a feature. An open redirect is a vulnerability where the attacker can link to a trusted domain, and control a redirect from the trusted website to any other untrusted site.

For example, the Libravatar and Gravatar APIs let you set a parameter for specifying a fallback avatar. For users without an avatar, the server can return the fallback image instead. You can set this parameter to URL and have the service redirect to this address as a fallback. The intention is that you can specify your own fallback image and redirect to it.

An attacker can use the redirect to leech off the reputation of a Libravatar server’s domain. An open redirect can be used to obscure a link’s true destination, or help a spam or phishing message to sneak past filters.

An open redirect is a common vulnerability, but the security community tries to shut them down whenever they’re discovered. What’s making this one noteworthy is that you can auto-discover Libravatar servers using DNS service discovery (DNS-SD) by querying domains for the DNS SRV records.

I DNS-SD queried the web’s top 5,1 million domains (Tranco list #44KX) to see how many Libravatar instances and open redirects I could find. In total, I discovered 18 instances (unique IP addresses) on 23 distinct domain names. 11 instances were vulnerable (13 domain names).

Notably, the servers operated by academic institutions were not vulnerable. These institutions are likely running custom software solutions on top of their staff and student databases to generate the avatars.

There are at least a dozen implementations of the Libravatar API. You can implement a simple version using static image files, a web server, and the DNS SRV records. Not all implementations support redirecting to a fallback image. I found six distinct vulnerable open-source implementations.

It was time to do something about this. I contacted the Libravatar project to report the vulnerability and suggested the removal of the open redirect from the specification. The project maintainer promptly removed this option from the specification and the reference implementation (ivatar). The reference implementation still supports redirects to a list of allowed domains. The maintainer made the issue public right away.

I then proceeded to contact the other vulnerable implementors and server instances I had discovered to notify them about the issue and the updated API specification. Three implementors and five server instances responded promptly within a day and pushed updates and patched their servers. Four days later, and I’ve not heard back from any more implementors or server instances.

I’ve found two of the open redirect server domains in the Cisco PhishTank phishing database, and two other domains in email spam blocklists. Two other of the server administrators I contacted volunteered log-confirmations of abuse of their open redirects.

So, what about the Gravatar API? Gravatar still supports a redirect to an arbitrary redirect. However, it doesn’t issue redirects. Instead, Gravatar proxies the request and verifies that it’s an image before serving it. The proxying slows down request handling compared to a redirect, but it’s more secure.