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 Internet Protocol (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 havenât 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.