-1

I have a doozy for you - almost posted this in the project management stack.

I was asked to oversee a development of a project.

At some point the previous manager thought it was prudent to create a backdoor deep in the guts of an obscure Java module.

Due to the nature of the project, it basically gains root access on the server as well as the "slave" servers.

We found out about it because the software sends a "I'm all set up!" email upon installation.

The South American team, within minutes, figured out who this guy was and what changes he was making to the code.

I'm not sure how it was leaked, but here's the more distilled questions:

  • What is the best way to prevent ourselves from being rooted? I'm told that it's possible albeit very difficult to figure out how it works by someone unfamiliar with the project
  • Is there a way to retain this "feature"? If it was stolen, the way I see it, everyone on the team is a suspect, so if it leaks AGAIN I'd like to have some way to at the very least find out.
  • What to do with a Mr ****, **** from *****?

More specifically:

A Java module of the software contains a way to figure out the password for the root user on the server, both master and (numerous) slaves. The way to get the root password is obfuscated among thousands of lines of code, but it only requires a single, pre-set token. I'm not too happy about that.

dsp_099
  • 165
  • 6
  • 6
    somehow this feels to me like a structural engineer saying "we figured out someone has been leaving bombs in the foundations of our skyscraper. How do we avoid that other people get access to the detonators?". And I feel like saying "by tearing down the skyscraper, and laying new foundations, and rebuilding atop of that, without *any* involvement of the parties that did that or didn't stop that" – Marcus Müller Dec 08 '16 at 02:24

2 Answers2

4

The best way to prevent yourself from being rooted would be to remove the backdoor from the project. If that is not possible your only other bet as far I can see would be to isolate the program in a container and setup very strict access control and ip filtering to try and mitigate the damage.

If you wish to retain the feature(I would not recommend this), it would be sensible to add strong authentication (certificates and passwords) to make sure that unauthenticated access does not happen.

Ask Mr **** why he did it, request he remove it, and unless he had approval from a whole lot of people and a good reason fire him.

kbh
  • 66
  • 3
2

This is really, really bad. You need to do the following:

  • If the system is running, shut it down. Do not start it up again until the issue is fixed. (You could consider running it behind some kind of firewall that blocks the exploit, but unless you are really sure you are in fact protected that would also be a risk.)
  • Assume that all your servers, including the slaves, have been compromised. Read this.
  • Fix the issue by removing the backdoor, even if it is complicated. Not doing this would be like saying "I got shot by a poisoned led bullet, but the doctor said it would require complicated surgery to remove it, so I just left it in my body."
  • Have someone external do a complete review of your code, to make sure there are not more hidden treasures in there somewhere.
  • Review your routines for commiting code to production. What can be done to stop things like this from slipping by in the future?

As for how to deal with Mr. X (and anyone else who knew about this) that question is not really on topic here and I don't know enough about his motivation to answer it anyway. But I would recommend you to get some serious legal advice on that.

Community
  • 1
Anders
  • 64,406
  • 24
  • 178
  • 215