Loophole is sending exploit attempts to my web server?!

[CherryDT]

When I start Loophole, I get this kind of "hacking attempt" requests on my webserver immediately. How is this possible? Surely nobody could guess the ID in your URL (especially not within seconds). Have you been hacked?

  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 2ms 3.71kb
  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 1ms 3.71kb
  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 1ms 3.71kb
  <-- GET /server 127.0.0.1
  --> GET /server 127.0.0.1 200 2ms 3.71kb
  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 2ms 3.71kb
  <-- GET /debug/default/view?panel=config 127.0.0.1
  --> GET /debug/default/view?panel=config 127.0.0.1 200 2ms 3.71kb
  <-- GET /v2/_catalog 127.0.0.1
  --> GET /v2/_catalog 127.0.0.1 200 2ms 3.71kb
  <-- GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application 127.0.0.1
  --> GET /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application 127.0.0.1 200 2ms 3.71kb
  <-- GET /server-status 127.0.0.1
  --> GET /server-status 127.0.0.1 200 1ms 3.71kb
  <-- GET /_all_dbs 127.0.0.1
  --> GET /_all_dbs 127.0.0.1 200 22ms 3.71kb
  <-- GET /.DS_Store 127.0.0.1
  --> GET /.DS_Store 127.0.0.1 404 1ms -
  <-- GET /.env 127.0.0.1
  --> GET /.env 127.0.0.1 404 0ms -
  <-- GET /s/2373e2632313e2130323e2833313/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties 127.0.0.1
  --> GET /s/2373e2632313e2130323e2833313/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties 127.0.0.1 200 3ms 3.71kb
  <-- GET /config.json 127.0.0.1
  --> GET /config.json 127.0.0.1 200 2ms 3.71kb
  <-- GET /telescope/requests 127.0.0.1
  --> GET /telescope/requests 127.0.0.1 200 2ms 3.71kb
  <-- GET /?rest_route=/wp/v2/users/ 127.0.0.1
  --> GET /?rest_route=/wp/v2/users/ 127.0.0.1 200 2ms 3.71kb
  <-- HEAD / 127.0.0.1
  --> HEAD / 127.0.0.1 200 1ms 3.71kb
  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 1ms 3.71kb
  <-- GET / 127.0.0.1
  --> GET / 127.0.0.1 200 1ms 3.71kb
  <-- GET /.git/config 127.0.0.1
  --> GET /.git/config 127.0.0.1 404 1ms -

[Morishiri]

Since we use Let's Encrypt that's possible that some "hacker" is watching the list of obtained let's encrypt certificates on https://crt.sh/ and tries to exploit them as soon as they are up. We were definitely not hacked and it's not us sending this requests. But please keep in mind that the obtained Let's Encrypt certificates list is public, so all loophole domains are in the end landing listed there.

[0x7f]

Hi @CherryDT you are the first one reporting this issues. As @Morishiri mentioned, the hostnames are public. Can you search your hostname on crt.sh and confirm it is listed there?

[CherryDT]

You are right, the certificates are listed. That's probably what's happening. I'm surprised I'm the first one talking about this though, as it was happening yesterday every time I started loophole (with different random domain). It's not happening today anymore though.

I guess it could be an issue for some people because dev servers often have lax security and one does not realize that starting loophole is effectively exposing the server to the entire world (there is a false sense of security from the unguessable URL). Perhaps a warning should be displayed? I think especially for beginners this could be very dangerous because it just takes one misconfigured static file server to have your Bitcoin stolen then, for example.

Of course it could be mitigated by techniques like making the random subdomain actually a sub-subdomain so you get random1.random2.loophole.site and issuing the certificate to *.random2.loophole.site using DNS validation on your end instead of the HTTP method. In this case the part random1 of the URL would never be public.

Something is still strange though, but that's probably a separate issue - I was also fooled by seeing 127.0.0.1 as the source of the traffic, it seems you are actually sending a header X-Forwarded-For: 127.0.0.1 which doesn't make sense (this header should have the remote IP). However that's not only with those requests, but with all requests, I just never noticed because I usually wasn't interested in the IP and I was used to seeing 127.0.0.1 there when testing something myself so I hadn't realized it should have shown a remote IP when I connected from my phone for example.

[LWFlouisa]

Is that why I keep having to restart this server? I have no way of controlling what certificates I have and that's entirely done on Loophole's end. This has never been an issue with Ngrok or Localtunnel.

[0x7f]

Hey, I think there is some misunderstanding here. The SSL certificate is handled by the cli on your computer only. Our backend servers are never involved when acquiring the certificate, nor do they terminate the SSL connection. The Let's Encrypt SDK is part of the cli and the cli is doing the full handshake needed to acquire the certificate. The private key of the SSL cert is never leaving your computer. Only you can decrypt the traffic sent to your loophole hostname.

That's also why we can not really go with DNS validation method. We could build some internal protocol so the cli is sending the DNS validation token to our backend which is then putting it into the DNS server, but I don't want to go down that route to be honest. That's why we go with single subdomain on loophole.site.

Adding a warning to the cli that makes it clear that the endpoint is public and can be discovered by anybody, is indeed a good idea. Feel free to open a PR if you want :) Also maybe a hint that you can easily protect your site via basic auth (https://loophole.cloud/docs/commands/http#options).

The X-Forwarded-For might be an issue in the reverse http proxy running as part of the cli (the one that does the http validation, ssl termination, etc.). We will look into that. In the end the cli does not know the actual client IP anyways, because the raw TCP connection comes from the loophole backend servers and we don't forward the client's IP there.

[CherryDT]

I understand. Basic auth can sometimes be an option but not always. For example, in my case it wouldn't work because the device that accesses this API through loophole already needs to send an Authorization: Bearer authentication token.

The thing with the IP now also makes sense, I didn't realize it was a raw tunnel with no metadata associated whatsoever.

I understand you don't want to over-complicate things but I really think a "secure out-of-the-box" solution to this would be important because there is a pretty high chance that applications that get tunnelled through loophole have security flaws or are entirely unprotected, as they are in the middle of development and are probably often not intended to be public at all, and the requirement to know a random address is normally good enough as "not public", but having that address published in a list (that most people don't even know about) where bad actors are just waiting for it to pop up so they can hack your computer and everything on it if you are unlucky, is, in my mind, a pretty dangerous situation.

For myself, I understand now what's happening and I know how to deal with it, but I'm just worried for others, especially beginners.

[0x7f]

I think I understand where these requests are coming from. We received a report from https://leakix.net/ about a user accidentally hosting his .git/config publicly via loophole. First, I misunderstood the report as abuse use, but on second look I figured it was just a notification about an accidental leak. It looks like leakix started scanning loophole tunnels for accidental leaks and this looks like a hacking attempt. I reached out to them to get more information. Will keep you posted.

Still, more warnings about the endpoints being public will indeed help increase the awareness. In the end, that is exactly what loophole is about - hosting stuff publicly. But the random hostnames might give a false sense of "undiscoverability"

[CherryDT]

Good to know, so this is actually a good thing then, sort of.

In the end, that is exactly what loophole is about - hosting stuff publicly.

Yes, but I do think that people (including myself) are used to thinking in three layers of "visibility" of things: Public/Discoverable (anyone can find and view your stuff), Public/Unlisted (anyone can view your stuff if they have the link which they can't guess), Private (only certain people can view your stuff, based on some sort of auth beyond a link). (Other people may not think in that terminology though.) That's how most stuff out there works, think of YouTube or Google Drive. And anything that doesn't have an obvious way for people to find your stuff in some list or such is automatically considered to be of the "Unlisted" nature (e.g. Dropbox links, links to Discord or Facebook attachments, "public" Evernote notes, etc.). My assumption is that most of the time, things made available over a tool like Loophole are not intended to be really "Public" in the "discoverable" sense, but just "Unlisted" because you need some devices or people to be able to access your stuff over the Internet easily (and usually temporarily), but that stuff is often not ready for production yet and hence likely to be not fully secured.

That's why I think a warning should be particular about the URL being discoverable over services such as crt.sh, not just "public" because I think "public" is ambiguous and often actually means "unlisted", and the random hostname would certainly make it appear so too.