Slashdot Mirror
Do You Write Backdoors?
quaxzarron asks: "I had a recent experience where one of our group of programmers wrote backdoors on some web applications we were developing, so that he could gain access to the main hosting server when the application went live. This got me thinking about how we are dependent on the integrity of the coders for the integrity of our applications. Yet in this case a more than casual glance would allow us to identify potentially malicious code. How does this work when the clients are companies who can't perform such checks - either because they don't know how, or because the code is too large or too complex? How often do companies developing code officially sanction backdoors...even if means calling them 'security features'? How often has the Slashdot crowd put a backdoor in the code they were developing either officially or otherwise? How sustainable is the 'trust' between the developer and the client?"
Here's a list of 1090 backdoors.
Some people write backdoors to facilitate debugging. They don't have to worry about checking with the customer for various passwords - they just type in "IAMGOD" or some such hard-coded password and they are in.
For the record, I don't approve of backdoors. First, they provide security issues - someone just has to look through the executable for strings. Second, these things are never changed when employees move on.
Occasionally I have been given a task to write a piece of software and I do not have an account on the system which I am writing the software for. The backdoor is designed to make sure test is working. So I basically put in code which basically says:
If User = Me then
bypass security
else
Security/Validation
end if
This way I can test the app without having to go and validate against the system which I don't have rights to. When we move from test to production, this backdoor is left in until the client validates user acceptance test(UAT) phases, at which point a second production move is done without the offending backdoor. In otherwords the backdoor is the first UAT bug reported.
I suspect this is common for contractors.
Ted
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
No, that was the random seed used to encrypt Frontpage connections to the server.
(Kinda funny actually, someone who had to support Netscape 4.x for any length of time must have wrote it.)
However, once the phrase was found out it made it easy to start cracking the encryption. So it was removed and replaced with something else.
People have been sucessfully sued for this practice.
If it's not fully outlined in the contract, he could have a really fun time in court.
The ultimate network admin tool needs HELP!
I work for a small web company developing web apps for other small-to-medium sized companies. The one thing that you learn when you're in a small software company is that nobody wants to pay their bills.
This is hard to see from a large-company perspective, because as a developer you aren't the one collecting the money, you have accountants and lawyers and rabid CEOs that make sure you get your contract's worth one way or another. But small companies don't have this option--they can't afford lawyers or even the time to spend in court. They have to find where their next paycheck is coming from.
As a result, many of our clients have tried to jerk us around by either dragging their heels on payments or doing something underhanded like changing passwords to servers to try to lock us out and give us the finger. There have been instances where I've sent out a "it's all done, check it out" email and had the live server's passwords changed on me minutes later, follwed by a "we're not paying" response.
Simply put, backdoors are a small company's only assurance that it will be paid for the work it has done. Given, the backdoors that I put in aren't to r00t the server or take down a whole subnet, they're limited to disabling the application that we developed. Until the client has paid their bills, it's still our code, and we have every right to put in as many backdoors as we want.
--My other sig is a ferrari.
In the past, I've included "secret" passwords at the request of the people who'd be going to the customer sites to help out. Often times you'd find the customer wasn't around to tell you their password when you needed to quickly get in and look at or fix something. I coded a fancy algorithm where password was dynamic based on the day of the week and the month name, but our field circus guys found it too hard to remember the algorith, so I was forced to change it to "*", which I considered very dangerous.
Another time, we had a one line message window - if you sent a message with a severity of 'w','e','s' (for warning, error, and severe respectively), the message would stay for progressively longer amounts of time before the next message could wipe it out, and it would flash different colours and beep for the more severe ones. For message type 'i' (information) it would immediately be replaced by any subsequent messages. Once when it was late at night and I was getting a bit punch drunk, I made one branch of the program put out the 'i' message "How the fuck did that happen?" followed immediately by a more informative 'e' message. Nobody ever saw the 'i' message, because it was replaced so quickly. Until one day when somebody put a scroll bar on the message window so you could scroll back and see previous message. I got a call from a trade show requesting an immediate patch. Ooops. That's the closest I've ever come to putting in an "easter egg".
I think putting in secret backdoors to get access without telling your superiors is very bad news, and could quite easily get you fired.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
Not All Backdoors Are Nefarious.
I was a senior software engineer at Whistle Communications, and later at IBM, for the Whistle InterJet/IBM Web Connections products. I did most of the last generation of email, user account management, mailing list, internal database, and other infrastructure services for the product.
This product has back doors. But they are all explicitly guarded.
From the front panel of the InterJet, you can enable remote management, for a short period of time. This allows a tier 1 support representative to help you configure/maintain your InterJet, while you are on the phone with them.
This required explicit customer consent for remote Web UI based administration.
From the Web UI, if you are logged in as "Admin", there are "secret URLs", which you can use to obtain raw access to the configuration database for much of the InterJet: all of the parts I personally wrote, and some of the rest of it, where the engineers used the standard APIs we had agreed upon for user interface and common configuration store code. This was done to work around the Web UI design, which failed to expose many useful features of the product, which we engineers knew would result in customers inability to use the product as it had been sold to them. It was likewise useful for tier 2 support, to avoid engineering escalations.
This required explicit customer consent for remote Web UI based administration.
Also from the front panel of the InterJet, you can enable "telnet mode". This was done by going to a particular configuration screen on the front panel, and entering a "T" (for "Telnet") on the front panel keypad at that screen. A time limited ability for a remote engineer to come in and manually access the system to diagnose and treat engineering escalations was thereby enabled.
This required explicit customer consent for remote shell based administration.
In addition, this mode only worked from a specific netblock of IP addresses.
Once in at the shell, it was possible for an engineer to force any of these protections. It was common practice for a persistant problem to leave the remote access for engineers open until the problem was verified to be resolved.
There was also a "magic" front panel sequence that would permit you to play "Pong" on the LCD display. I filed a sev-1 bug ("total loss of functionality") against the maintainer, because it did not support "Skunks" (scores of 7-0) as a victory condition. 8-).
All of them were under direct user control, in terms of outside access.
None of these are "proprietary" or "confidential", they just aren't useful to people without documentation.
Other than working around the Web UI designer's intent, with the second back door, none of these really qualifies as nefarious (I would argue that working around the Web UI designers intent qualifies as "routing around the damage").
-- Terry
A backdoor is a socket bound to a public interface that is undocumented.
If the coder was good enough to handle your app, he's good enough to write a robust and secure backdoor.
If you want to know what an app is doing when you run it, run it under strace, and you will know everything it does.
If it's a windows app then don't even worry about it, cuz you've already lost the game.
Back in the days of GOD (Good Ol' DOS) the variable memory need would grow too large for that reserved, needing tweaking. Or a scratch database would get corrupt from a hardware failure.
Almost all things that could go wrong could be corrected without having to tear the code apart...because it always worked in my development systems; it only broke in production environments. The "backdoors" proved invaluable for tending to the screwups of the DEUs (Defective End Users :)- example: one of my clients had forgotten to use the AR functions and had literally MILLIONS of dollars owed to them in the system (only), all because they never entered checks received. Arghhh!
db
Cig:
ôô
Really? The computers would literally sigh from boredom? Since when do computers literally sigh? Or feel boredom? "Literally" is not to be used for emphasis; especially when you're applying it to something you mean figuratively.
And how does that differ from normal prejudice?
There is compliant disposition of employment and then there is non-compliant disposition. Picture a couple of burly security guards with an empty cardboard box explaining to you that you need to turn in your security credentials and pack your personal possessions under supervision during the next 5 minutes before being "escorted" off of the premises.
Contrast that with the picture of a large party being thrown in your name as you complete your "two weeks notice" into early retirement for a job well done after a career of successes.
Speak truth to power.
If you want to hide your source, you can easily obfuscate. For example, I would suggest applying "gzip" to the final build. Then you can run the program by invoking "gcat" on it, and piping it to "/usr/bin/perl".
For example:
$ gzip test.pl
$ mv test.pl.gz test.pl
$ zcat test.pl | perl
This would probably work well enough to hide source from non-techies.
We should never forget that the first big Internet worm spread itself largely though a back door written into sendmail. The author, Eric Allman, deliberately put in two backdoors as SMTP commands, "DEBUG" and "WIZ", one of which (DEBUG) was used by Robert Morris's worm. While Google can't seem to locate it, there was a contemporary statement by Allman that the reason for those two commands was a Berkeley sysadmin who wouldn't give him privileges to update sendmail, so he did it himself, the hard way.
Anyone who writes a backdoor should be fired ASAP and the door should be closed. Failing to do so can easily make your company liable for damages caused by someone using it. It's a miracle that Allman didn't get prosecuted with Morris - he probably would today, but the legal folks were more clueless about computing risks in those days.
If I can't log in as an arbitrary user, then I can't fully test the system. Everyone had different preferences and details, and I, as the master user can't do all that much from my account.
I think you misunderstand what my message meant: I don't have a "master" mode, I have a overriding password that bypasses the standard authentication system and lets the admin user assume the username/authentication details of an arbitrary user. That's important so I can have the same experience as that user. It doesn't compromise any data security, as I can just as easily see all the user's data when it's sitting on the database server.
This is clearly not true. Any method of gaining access that circumnavigates the established security procedures is a back door.
If they fire him tomorrow, they have no way of removing his access from the system, since they don't even know it's there
Everyone seems to focus on the actual piece of code that acts as a 'backdoor' and forgets that just knowledge of the system is just as dangerous. No sufficiently complex system can be foolproof both in design and implementation. During developent debugging code gets left over, some shortcuts are taken, etc.etc. Nobody except the developers who designed and wrote the stuff even know about what exactly is in the code. While I do not put any backdoors in my code intentionally, I have the sufficient knowledge of the system to poke a few holes big enough for a full compromise.
In short: If you have a sufficiently large system, chances are that a disgruntled developer can compromise or damage it even without placing any backdoors in the code ahead of time. Knowledge is power. Obviously, this does not apply to open-source projects that receive a fair amount of peer review (or just people tinkering with the code).
Jobs? Which jobs?
When I said my servers were running a daemon that allowed remote root logins, I wasn't meaning in the sense that they were open to Internet at large.
All of the servers I was dealing with were on our internal LAN and behind our firewall. The application in question was a daemon that was supposed to listen on a given port. In fact, we had scans set up to monitor and alert us if the service went down. So our portscans showed it as a listening port as it should have. We would have had to put a sniffer against it to see that it was passing traffic that it wasn't supposed to.
I am not saying I couldn't have detected that the daemon was doing a bit more than it ought to but it wasn't quite as simple as you suggest.
You're not developing the project for a "master user," you're developing it for normal users. Debugging code while in the "master" mode will do nothing more than give you a false sense of whether your code is buggy or not.
You seem to be confused on the issue here. If you're trying to get a sense of whether your code is buggy or not, that's not debugging, that's testing. If you're debugging, you already know your code is buggy -- you're trying to find out why (or how) it's broken.
When you test things in "normal" mode, and something fails, you enter into "master" mode to find out what's going wrong.
I was working on a small custom db (in c, way back in the PC dark ages)that was going to hold confidential data, and had a simple user login coded up. Management insisted on putting in a back-door because past experience indicated that a few times a year a customer would ask us to "recover" a lost password. The back door was used to get into the system as an admin and reset the other user passwords for customers.
Anarchists never rule
Don't do it.