Dark Web Diaries: Discovering i2p Router Consoles

by Sarah Jamie Lewis

Note: This is a new series of posts chronically some of the more extreme examples of operational security failures discovered by OnionScan

For our first entry we present what appears to be a couple of seemingly deliberate attempts to access local i2p router consoles via hidden services.

Both consoles appears to use Vietnamese language settings with one being associated with a Hungarian IP address.

This kind of setup is an astonishingly bad idea. Not only does the simple act of being able to view the console leak information about the operators and the router, the router consoles are also only intended to be accessed by locally privileged users and as such allow a user to take certain actions, like updating, restarting or shutting down the node:

The main update section from the sidebar of one of the routers showing the restart and shutdown buttons as well as the i2p version and network status.

The main theory are that both of these services were setup intentionally by users who didn't understand that hidden services can be discovered i.e. that just keeping the address secret is not sufficient for hiding the service from the world.

A collection of graphs showing the performance of one of the i2p routers.

Ideally, the i2p console and other software would be able to distinguish between a truly local user, and a user that was coming from an anonymity network like Tor - however this is currently not the case.

This usability issue extends far beyond the router console and impacts many web servers and applications e.g. the now infamous Apache mod_status leaks

i2p are now tracking this issue*, researching and investigating a number of potential options to protect users from themselves in scenarios such as this - from requiring authorization to access the console by default to simply detecting and blocking the Tor Browser from accessing the router console (or at least display a warning).

A true, universal fix to this and other related localhost bypasses is likely far off in the future, and it may be that we have to design all software to assume that all connections, even ones appearing to come from the local machine, are not to be trusted until they can prove otherwise.

* I would like to thank @str4d for their input on this case and tracking this issue.