Gembuster - Enumerating the Small Web
I'm a big fan of the {dir,go,ferox}buster family of webserver enumeration tools*. I love them. They work a treat. And for all its faults, I'm also a fan of the Gemini protocol.
*honourable mention to ffuf
Motivation
I hate what the world wide web has become. You can't just "surf" it anymore. These darn "java scripts" with their "cookies" and "web assemblies" have gone too far, and there are now more headers than content in the average HTTP exchange (true). If it wasn't bad enough, they have invaded our desktops and everything is now a damn Electron app. My RAM has been confiscated by Chromium and is being auctioned off to Sam Altman as we speak.
It's only natural that people are fighting back through efforts like the Gemini protocol, an HTTP/S alternative that is barebones by design; no tracking or client-side scripting, with a simple desire to "get back to basics". Raw information (dubbed "gemtext") hurled straight to your screen over wonky, stateless TLS. There are some nice terminal clients such as amfora that make the browsing experience quite pleasant. Gemini sounds great in principle, but to think it will amount to anything more than a hyper-niche alternative to HTTP is a bit silly. Daniel Stenberg of curl fame gave a great critique of the protocol a while back, and not much seems to have changed since then. Regardless, it's fun to play around with - and simple enough to build tools for!
I assumed making tools for enumerating Gemini servers would be relatively easy given the Gemini specification could be written on the door of a bathroom stall or sufficiently large napkin. Funnily enough, the hardest part of this project was finding the spec itself, which appears to be hosted via a HTTP proxy. This may not do wonders for its SEO (or whatever you call that stuff). It doesn't help that Google's flagship LLM of the same name dominates all Gemini-related search results. Whether there is a valid conspiracy behind said naming is left as an exercise to the reader.
To the Moon
Anyways, in the spirit of "enumerate all the things" I wrote a gemini:// directory busting tool in Go.
It has the basic functionality of other *buster tools, sans recursion. That'd be one step too far. It's easy to use as well, as the syntax is identical to other tools.
gembuster dir -u geminiserver.com -w raft-common-directories-blah.txt
Since Gemini has no explicit Host header for specifying a virtual host (or any request header for that matter), I initially thought adding subdomain fuzzing would be pointless. However, recall a basic Gemini request is like so as per the spec:
gemini://example.com/index.html
The domain is sent in the request URI - as opposed to HTTP, where the URI is split into the path and Host header:
GET /index.html HTTP/1.1
Host: example.com
Even though the specification makes ZERO reference to the concept of virtual hosts and what the server should do with the provided hostname, one could assume that this could allow us to fuzz them, pending the implementation of the target server.
I decided to have a look regardless. I had a look at agate - a popular Gemini server implementation - and found that it implements hostname checking and virtual hosts!
[main.rs]
<SNIP>
opts.optmulti(
"",
"hostname",
"Domain name of this Gemini server, enables checking hostname and port in requests. (multiple occurences means basic vhosts)",
"NAME",
);
<SNIP>
As it turns out, so does jetforce, another popular implementation. And so I added vhost enumeration.
Check out gembuster here!
Retro
As far as I'm aware, this is the first enumeration tool that targets the Gemini protocol; not that there is much to target in the first place anyways. Do let me know if this is fake news.
It's hard to say where Gemini as a protocol will go in terms of adoption, and even harder to imagine this tool will ever be used. They really need to figure that 1-TLS-handshake-per-request issue. Regardless, i'm keen to see what this rage against the proverbial HTTP machine amounts to.