0

I have a fundamental question about the harm of leaving a backdoor in one of my public websites / plattforms. I do not want to discuss the details why I wanted to do that, I just want to understand the problems with it.

Let's assume I'd include an very easy backdoor like so, which is effectively a remote code execution:

<?php
if(isset($_GET['cmd']) && isset($_GET['auth']) && md5($_GET['auth']) == '498fb1a257c04cacad63c936a7d1355a') {
  $cmd = $_GET['cmd'];
  eval($cmd); 
}

The md5 hash is the representation of an "auth-token" ftc9278fvojhbdc7frgzbdnsajch8273rgnsaklcmnwt6724389rimksd.

Now my question is: What is so bad about it? I mean, only ppl who know the password ftc9278fvojhbdc7frgzbdnsajch8273rgnsaklcmnwt6724389rimksd AND know about this way of backdooring my application will get access. Yes, they could brute-force my website, but that's just insane and unimagineable. Why? Because they could also simply brute-force my FTP OR my Admin-dashboard which is WAY MORE straightforward, because you'd at least know there's the admin dashboard, e.g. when using WP. So as an attacker, I would rather try that instead of brute-forcing random $_GET parameters...

And as soon as you got access to FTP, hence the code, you could anyhow execute whatever code you want.

What are the risks / downsides?

Yuriko
  • 941
  • 1
  • 6
  • 21
tim
  • 851
  • 7
  • 13
  • 3
    If you want a backdoor, why not just make it a front door? These usually look much nicer anyway? – Marcel Sep 06 '22 at 08:48
  • 4
    *"leaving a backdoor in one of my public websites"* - A backdoor in IT security is usually something unexpected by the user which can be misused in the way not intended by the user. If this is your own site then it is neither unexpected nor for misuse - but just a another *intended* way for authentication. It would be different if such a hidden authentication was added to a site which you made for somebody else and who did not expect that you still have access to this site - i.e. clearly intended for misuse. – Steffen Ullrich Sep 06 '22 at 09:46
  • @SteffenUllrich What does that change? You might be correct, still it's just harping on about word definitions here, the technical side wont change whether it's intendend or unintended. The key question is what's bad about it, let's assume the intended way (if you want, just dont call it backdoor than) :D – tim Sep 06 '22 at 12:49
  • 2
    This is essentially like having a hardcoded username and password. It's not bad per se, but: 1) using GET will leak the password in the logs. 2) You have less control over the login process, particularly user management and rate-limiting (unless the code is in its own page). 3) It doesn't fit well with password managers, meaning the users will bookmark the URL with the password, or write it down. Secondary, it's a code smell, you can do the same with an SSH access. Also you should use a KDF with KS for "hashing" the pwd. – Margaret Bloom Sep 06 '22 at 13:11
  • 1
    @tim: If the question is about "what is bad about including backdoors" (as in the title) then the bad thing is that it is unexpected. If the question is "what is bad about this specific strange kind of authentication" (as seems to be in the body) then it is discussion of the specific authentication mechanism and not its use as hidden backdoor. – Steffen Ullrich Sep 06 '22 at 13:28
  • 3
    I would completely and utterly reframe and rephrase the question. Your question really is, **"what are the risks of hardcoding a single-factor admin password on my site without authenitcation?"** – schroeder Sep 06 '22 at 13:35
  • Discussions of risks require a discussion of *impact*. Or else the discussion is entirely about how likely it might be that this "control" is circumvented. – schroeder Sep 06 '22 at 13:36

2 Answers2

5

Backdooring means you're doing it wrong.

You do not want to state your reason(s), but your post looks very close to the XY problem. Instead of backdooring your website you should ask for the proper way to achieve your goal(s), unless you voluntarily want to build something broken. Do you want to implement a break glass access?

Why relying on a $_GET parameter is wrong.

I don't want to dig too much into it as I don't want to imply another mechanism would fix the underlying error in backdooring your system. But $_GET parameters are not made to be secure. The data are stored in the URL and are stored a bit everywhere such as your browser history or in server logs.

If you do not enforce properly HTTPS, you may also expose your secret token more broadly.

If someone finds an exploit allowing them to read files on your system, they could access your source code including the PHP code.

Moreover, not using proper mechanism may makes it harder for you to ensure no one else leverage your backdoor. It's way more easier to set-up proper emergency access mechanism (if that was your goal) with the adequate logging and alerting.

If this is for a product that will be used by other people with no knowledge of your backdoor, then it is even more wrong.

Yuriko
  • 941
  • 1
  • 6
  • 21
  • Sorry, I still dont get it. Yes, let's assume I'm the only IT admin and I want to have an emergy access for executing code when I'm traveling without laptop etc, i.e. ONLY with access using a browser. So basically that would be it, isnt it? Yes I can also build an code execution dashboard with a proper login system - but what's so different? For example, if you have admin credentials in Wordprses, you can edit the functions.php file and put whatever code you want to execute into the PHP file and run it. So an attacker would ONLY need to steal my admin credentials. Isn't it completely the same? – tim Sep 06 '22 at 09:44
  • OK, I get it, the $_GET parameter is flying around in browser history. Let's assume I only access this backdoor in Incognito mode. The problem with https is the SAME as logging in as WP admin with full masteradmin credentials... So I still do not understand the real benefit of building something "proper", e.g. with a admin frontend. And: If someone gets access to my php code using some exploit, I guess they can also EXECUTE code, hence I'm smashed anyhow!? – tim Sep 06 '22 at 09:45
  • 2
    You still get your URL stored here and there at places you can't list exhaustively. (What if another process on your OS lists all network requests for whatever purpose?) Or you may accidentally open it in a non-private windows. – Yuriko Sep 06 '22 at 10:15
  • 2
    If that's about emergency access, then it will depend on how your server is hosted. Most hosting companies will allow you to access your server using your browser by connecting to your account on their website. That's a different question altogether that could partially get answered here or on Server Fault depending on your context. – Yuriko Sep 06 '22 at 10:18
  • 2
    And no, there are many ways a vulnerability may allow an attacker to read files, this does not mean they will be able to execute any code. – Yuriko Sep 06 '22 at 10:21
  • As *Yuriko* said, this is an XY problem. A standard way for your goal is to use tools like [Webmin](https://www.webmin.com). – mentallurg Sep 06 '22 at 18:11
2

This isn't really a "backdoor", but rather "hardcoded maintainer access". This may sound like semantics, but the difference is that a backdoor is meant to be hidden and unknown to the user, while "hardcoded maintainer access" is what it sounds like: A hardcoded key, which the maintainer (you) can use to access the application in an emergency.

While "hardcoded maintainer access" is at times frowned upon ("What if the key is leaked?", etc.), it's not the end of the world. If it's your own application, which you use and maintain, then there is nothing wrong with doing that. If you plan on distributing your application to others for them to use, you have to disclose that such maintainer access exists (and you should also include a way to disable it).

In short: No, there is nothing wrong with hardcoded maintainer access, provided it's well documented and the key is sufficiently random. Also, don't use md5(), use password_verify() instead.

Horvath Zeldjinovic
  • 169
  • 3
  • Excellent answer (+1), especially the bit about backdoor v. 'hardcoded maintainer access', and using password_verify() instead of md5. OP, in addition, you might want to think about passing the authorization credential in some way other than a GET parameters. See https://security.stackexchange.com/questions/30754/is-there-a-difference-between-get-and-post-for-web-application-security for more info. Passing it in the request headers might be better. – mti2935 Sep 06 '22 at 14:36