My client says that one of his old developers found some code that allowed a past developer to access the site in certain ways. She wrote code to allow herself to log in to certain restricted areas and to send herself emails when certain things happened on the site, for example user sign up.

My client now wants to make sure that this is not going on. He has asked me to do this by looking over all the source code. Now that might be useful, but what is the best way to rule out that a past developer is using something like a backdoor to still access the site?

  • 1
    Prosecuting the employee who was caught might be a great discouragement to future problems. – Neil Smithline Sep 9 '15 at 2:41
  • 4
    What language and framework is the site written in? – David Waters Sep 9 '15 at 4:52
  • 2
    The only solution is to review all the code by an experienced developer. Also note that backdoors may appear as simple bugs, giving plausible deniability to the original author, so the reviewer should also catch those and fix them. – André Borie Sep 9 '15 at 7:32
  • 1
    "send herself emails when certain things happened". If the first priority is to determine if the backdoor is indeed there, look at the email logs and determine if any emails are send to the user at regular intervals. If she is a former employee, she shouldn't be getting any emails from your server and her account should be locked. – void_in Sep 9 '15 at 8:48
  • 1
    In my experience as developer, sometimes those codes have some reason, like remote debugging the system, monitoring some functions or just simplifying the technical support process. To identify if its actually an intentional backdoor, I would look into: 1) sensitive information is being sent to a personal email (email outside the organization). 2) The piece of code seems obfuscated or unnecessarily complicated. 3) The piece of code is not where it should be (e.g. login through an image file) 4) Its clearly against the company agreement. Its better to contact that developer and ask her reasons. – lepe Sep 10 '15 at 0:57

There are infinite many ways a developer can place intentional and unintentional backdoors into code. When the developer is skilled, they can hide them well and/or mask them in a way which appears like an unintentional mistake. A complete code-review is the only way to achieve reasonable certainty that further backdoors are unlikely to exist. But there is really no sure way to completely rule out the existence of backdoors.

When you are in a hurry, you could at least try to rule out the most obvious things before you start investigating the complete code line-by-line:

  • Take a look at the login and authentication code - this is the most obvious place to have a magic parameter, universal password or hardcoded credentials which allows one to log in without a valid account.
  • Check if there are any scripts in the codebase which don't appear to be referenced anywhere - they could be a hidden control panel or similar.
  • When email messages in particular are a concern, grep the websites codebase for those functions which send emails in your programming language. You could also monitor the webservers traffic for outgoing SMTP traffic to notice any emails which do not match the format usually sent by the application (when it is supposed to send emails at all).

By the way: This might also be a topic for your legal department to address. Backdooring the application is likely a breach of contract and might even be a felony in your jurisdiction.


Having been there in the past with clients - here are some practical measures to rule out that developers (employee or contractor) left back-doors in the code to access the site.

  1. Remove all the credentials for the person who left from the Web server (for example basic authentication credentials), operating system users, database users, mail server users. Do that now and make it a SOP when people leave.
  2. Review the list of users with SUDO privileges (or administrator if you are on Windows). Prune out all the sudo users you don't know or trust. If someone needs sudo - they will ask for it and you will ask for a justification
  3. Grep the security log for breakin attempts and grep the web server log for occurences of names that sound like the developer who left. Shut down FTP services.
  4. If you are on Linux and running Samba - check allowed permissions - remove users who no longer work for the company Grep all the source code for the person's name or email - if you get a hit, clean out the code
  5. Assuming you use svn or git - examine all the commits the developer performed 1 week before he left or was fired. Most of the nefarious stuff happens close to termination. Review the code manually and with grep and look specifically for exceptions to authentication based on a username, a magic parameter in a query string, a time of day or an IP address. Any code that says if something ! authenticate is suspect.
  6. Assuming you use an MVC framework like RoR or CakePHP - examine your acl tables and examine the authentication controller for exceptions as in the previous point
  7. Post-exploit - implement a SOP to sweep through your OS and Web app users periodically and remove unused accounts/accounts of people who left/accounts with unneeded privilege.
  • 1
    a backdoor doesn't necessarily use credentials. – elsadek Sep 9 '15 at 7:49
  • Your answer focuses on operating-system level security. But the question explicitly says "She wrote code to allow herself..." which obviously meanst the question is primarily about application level backdoors. – Philipp Sep 9 '15 at 8:55
  • @Philipp - My answer explicitly looks at code in items 4, 5, 6 and is a systematic approach working down the stack from the operating system, to the web server, to the web app framework to app code. – Danny Lieberman Sep 9 '15 at 9:14
  • @elsadek Correct but the person asking the question suspects that the attacker would be able to login and that requires credentials. Past experience tells us that Web app backdoors typically use privileged accounts (which were never removed when the person left) and/or conditional logic to bypass authentication/authorization. In item 5, I also suggest looking for magic parameters in query strings which could be used to exploit elevation of privilege to the database in all kinds of ways from a piece of code to a stored procedure; which would still involve some kind of access control violation – Danny Lieberman Sep 9 '15 at 9:19

It depends on how thorough you want to be. Here is a list of places to start in ascending order of effort.

  1. Replace all binary/javascript dependancies with fresh copies
  2. Ensure the Authentication and Authorisation code is centralised and as simple as possible, preferably centrally configured. If the login or Authorisation code is complex it may be worth rewriting.
  3. Think of all the sensitive actions the site could take e.g. sending an email, making a network connection. Find all occurrences of these actions and review them.
  4. Depending on the size of the site and the budget you have do a through review of the whole codebase.
  5. If the developer had access to the server, re-image the server (Paranoia Level High)

If you do not feel confident in your ability to do this code review there are companies that specialise in security who will do a review for you.

  • The first order of business is ruling out the back door - changes to Auth architectures and production instances are time-consuming and risky. For example - replacing all binary/JS dependencies with fresh copies.. Assuming there is a back door - it will be in the "fresh copy" as well. Most Web application instances are more complex than reinstalling a desktop application and have large numbers of OS and software component dependencies. Sure you can create a new instance of a web server, db server, and middle tier servers but while you are busy doing that, the back door is open. – Danny Lieberman Sep 9 '15 at 7:19
  • Time is the constraining factor – Danny Lieberman Sep 9 '15 at 7:26

This depends on your security / policy stance. The main problem with something of this nature is, code dependency. Especially on legacy code and libraries. The lines of code make it virtually impossible to vet any single one part of the code. This is especially true if the developer replaces parts of the stack, which is why reproducible builds are important, or at least the ability to diff across differences. This might not be possible for old installs, and the lack of ownership.

Centralised vs decentralised access is a compromise between administrative workload, as well as the mitigation process in place once one part of the system is breached. Do you have enough people to do this? And can this be automated?

In general, the days of finangling each install and not having a coherent mitigation process as part of the overall whole, is past. And, you cannot rule out to a definite degree the website has not been compromised to some extent.

  • The question relates to access control and not to higher level security policies. It is a specific issue related to back-doors left in code by employees/contractors that left or were terminated. – Danny Lieberman Sep 9 '15 at 7:03
  • 1
    The piece meal approach to defence is less tenable than a layered approach. It's important to keep this in mind when going through the checks on the system itself. Also since the combinatorial complexity increases with age and dependencies, a broader understanding helps with knowing when you've done enough or whether it's something that's fully impossible to lock down. – munchkin Sep 9 '15 at 7:38
  • My experience with backdoors is that time is critical. You are correct in asserting that there are multiple layers to assess: OS, Web server, DB server, Web app framework, Messaging services and code. At the end of the day - most back doors by disgruntled employees use their own credentials and are pretty blatant in the code. When tracking down a backdoor - you may start at any point in the stack, whatever your gut tells you but at some point you will be moving up and down and sideways tracking down the suspect. Not a time for architects, process engineering and ISO standards. – Danny Lieberman Sep 9 '15 at 8:02
  • It is probable but it would be too simplistic to assume that a disgruntled employee, especially an administrator, would use their own credentials to access the system. Hence that one comment about credentials, from another user. And, my statement about keeping the layered approach in mind, is about how to figure out when enough spelunking through the code is enough before thinking about acceptable losses. – munchkin Sep 9 '15 at 8:24
  • You'd be surprised. In my experience with DLP and data breach audits, people always use their own credentials or credentials of a bona-fide user ( widen the search to friends in the company, people they're tight with ...). Yes - it's a question of how much time you want to spend and that is a question of the value of the assets at risk which should always be the first order of the day. – Danny Lieberman Sep 9 '15 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.