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?"

Comments

I backdoor all the time..

[japhar81]

But, thats not to say I lack ethics, am a cracker, or am out to get my client.

How many times have we all heard, duhh.... I forgot my admin password, but I cant reinstall, I need the data.

So yes, I backdoor, and I document it internally (hardcopy stored in a safe). Its just an extra insurance policy for when some moron that I worked for 6 years ago does something stupid.

That said, coding backdoors for the sake of getting access to a web farm so you can host your own services is certainly a bad thing(tm). But hell, what are you gonna do? Everyone backdoors. Don't believe me? Watch someone 'in the know' log in to a random windows box using the System account and come talk to me.

Depends on the backdoor.

[phorm]

Some of the apps I make have the option to "allow" a backdoor by setting a flag (default on). The client can turn it off if he/she really doesn't trust me, but in most cases they find it useful in case I ever have to bugfix the systems and/or they lose their own passwords.

Payment Insurance

[BadBlood]

I know a person who owns his own company and writes code on a for-hire basis. He puts in timed expiration code such that if they don't pay him within 30 days of delivery, his code de-activates.

Where I work, we do similar things, but our motivation is to ensure that users are always running the latest version of our frequently updated codebase. We, as developers, do have the ability to run expired code via the backdoor.

Re:Payment Insurance

[B1LL_GAT3Z]

I was once commissioned to write a web application that dealt with secure signature technology. As the deadline came up, the dealings with my employer became "shady" - meaning that it looked like he wasn't going to pay out at the end. I wanted to do something similar to what you stated (an auto-timeout) however this application was written in an open source language (Perl) and needed to be kept that way. So - with some quick obfuscating I wrote a quick feature so that at a later date, if the employer didn't pay, I could simply access http://website.com/perl.pl?delete=y and it would delete itself. I'm glad I added this "feature" because it wasn't long after that he "disappeared" claiming all sorts of reasons for his non-payment. I then quickly used my feature and was glad for it.

Of course, if my employer was skilled enough, he could've gone in and removed the code himself. This leads to the point of the trouble of joining Open Source and backdoors - as it's virtually impossible to do without some skilled programmer looking at it and being able to remove it. I thought you mind find that to be interesting.

Re:Payment Insurance

[Ian Bicking]

I worked before for someone who had code like that put into his application (without his knowledge, of course). There was some pay dispute, and the programmer started triggering it. In this case it deleted the customer database, not the code. Ultimately the programmer was charged criminally (still awaiting trial), and possibly a civil case following.

Now, I have a feeling there was bad stuff on both sides (and it's taken me a while to extract myself from this job), but you have to be careful when you destroy stuff. It's probably okay when you are deleting something that is your property and isn't paid for. But it's questionable if he already paid for part of the work, or if you were destroying any data created by his operations. If any money had been paid, or if it would compromise data that didn't belong to me, I wouldn't try it unless I had written something into the contract (I've seen pretty generic-looking contract terms which would imply you could effectively confiscate the work if it wasn't paid for). You also need to define when it's not paid for -- 30 days after completion, 60 days...? It's not professional to do something so forceful without making an effort to resolve things more peacefully.

Backdoor?

[RobertTaylor]

"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."

Its like that theory that BAE /Mcdonnel-Douglas embedded the F15 Eagle fighter plane with a backdoor in its computer systems so if its ever used against the USA it will strangely malfunction.

Unlikely, but interesting concept all the same!

Re:Backdoor?

[zlexiss]

While there's a few unsubstantiated rumors floating on this topic (cites?), control of spare parts is much more effective than backdoors in code.

Iran's F-14 force was effectively grounded by the embargo Carter placed after the fall of the Shah - fighters and other complex equipment need a steady stream of parts, and a veritable torrent under non-peacetime use. Search fas.org or aerospaceweb for "iran f-14" for a couple views on this, among other sites.

As pointed out, backdoors carry the risk of being used against you. But if you've got all the spare parts, you get to fly.

trust...

[TechnoVooDooDaddy]

Trust and loyalty used to be my main focus... I trusted that those stock options i was offered instead of a chunk of salary would be good, and the company trusted that i would deliver good software, on-time.

I fulfilled my part of the bargain, but when it came to stock option maturity time, I got laid-off.. The company is still in business interestingly enough, and now posting profits even.

Who do you trust, and how is that trust repaid? I can tell you I no longer have the same sense of loyalty and trust in my employer. Companies are paying on average HALF of what they were for the same work 2 years ago.. Trust... works both ways or it doesn't work at all...

Backdoors

[JSkills]

Never written one for malicious pruposes before. Thought about it a lot of course - in the same way people fantasize about robbing a bank or hitting the lottery.

But when you think about it, all leaving a backdoor in a system does for you is to provide an opportunity of accessing a system in a way that you shouldn't be. This can lead to trouble down the line.

Clearly, there are legitimate uses for backdoors (to use in case of emergencies, etc.), but unless the backdoor is documented someplace for others in the software development group to be aware of, it's likely the kind of backdoor that is simply not ethical to implement, since it's only usable by one person.

I'm sure people can provide examples that disprove this, but for the majority of situations, as a developer, having a backdoor in a system can only lead to a security breach at some point ...

kind of...

[deander2]

I am working on an app for the govt, and yes, I have programmed in a backdoor login, as it's very useful for testing and development.

However, the following are true:
1) management knows full well of its existence
2) BY DEFAULT, it is turned off in any build
3) it is NEVER to be deployed turned on

I think it's a good rule of thumb.

PHP Web-apps

[yamcha666]

I work for a small startup that specializes in custom web-applications for indy record labels and small-time bands and clubs. Our main product is a all-in-one web-app that will allow the customer to manage their shows, news, mailing list and numurous other things.

We offer several levels of this product, one being shared (get 1 account on our servers) which we control, standalone, and custom standalone (the standalones go on their own servers.) The latter two are designed to have one back-door login account for myself and the other programmer to go in there and edit their settings or database if the customer breaks something.

So there is my 2 cents. Yes, I put small backdoors in my company's web-apps per boss's request.

Sure...

[Anonymous Coward]

Backdoors were coded into systems. But only for testing and development purposes. Once the software was being prepared for release, those backdoors would be deleted but in any case, they were usually coded to only work on specific (i.e. the development) machines.

What really concerned me though was when we were supposed to store credit card numbers encrypted in the database and I used a simple replacement cypher as a placeholder. Then, when I later asked about putting real encryption routines in was told "we aren't going to do that".

So customers are really in the dark when it comes to the security of their software.

Rich

Inadvertent Backdoors

[egg troll]

I know of a couple of examples where backdoors were put in for QA purposes and then left in when the product was shipped. Indeed, waaaay back in the day, a Mac IRC client left in a /ctcp command that would let another user execute any command on another ircle user's box!

Doing things like /ctcp B1FF exec /quit made IRC almost unuseable for Mac users for a week or so.

Anyways, my point is that most backdoors put in by developers seem to be accidental rather than intentional.

consequences

[spoonyfork]

I don't but two guys here did just that last year. It was a customer facing website for a large multi-national corporation. The "backdoor" was caught before going live but they were fired with extreme prejudice.

Re:Microsoft believes in them..

[e2d2]

I know that probably was a joke but.. If you think the NSA needs a key to get to your data you need to go read up on the amount of computing power they have in their hands. I recommend "Puzzle Palace" and "Body of Secrets" from James Bamford. Really interesting stuff. They could basically pick through your weak built in encryption like Rosie Odonnell picks through a rack of ribs. Their computers would literally sigh from boredom.

Make sure you get paid.

[ClioCJS]

A friend of mine did some web-work for $12,000.

The guy decided to be a dick about it and not pay him the money he deserved.

Fortunately for him he put a backdoor in. He told the guy about it. Once activated the system would not work until a password only he knew was entered.

His payment was promptly received. (He got the idea from a movie.)

the short answer

[Ender Ryan]

The short answer to your question is, "Yes". Over a long enough timeline with enough people looking at the code, backdoors get caught. There was recently, well, maybe 1 year, a backdoor found in an Open Source database that used to be a proprietary product. The backdoor had been there for the entire life of the product. However, it took over a year after becoming open source for it to be caught.

MS Easter Eggs

[pdrome4robert]

A microserf friend once told me MS had no policy either way on easter eggs. They were there if programmers took the time to put them there. If an easter egg can get through development, peer-review, testing, packaging, why couldn't a backdoor?

Time to become a contractor!

[Kostya]

You are now ready to be a contractor/mercenary. When I embarked on being a contractor, my friend who was a long-time contractor (20+ years) said after talking with me, "I think you are bitter enough now to become a contractor."

Which is to say, most people who went into contracting did so just because of stories like you told. They got tired of being jerked around and decided a little uncertainty and paperwork was worth getting little freedom from the corporate brain washing about team and loyalty.

Granted, many went into it because of money during the dot-com boom. They are no longer contractors now ;-)

I'm loyal--to getting the job done, according to contract, as long as I'm getting paid. I produce results, give advice, and let the customer go his own way--even if they insist on taking themselves to hell in a handbasket.

It beats getting all worked up over stupid stuff at work.

I always loved the "We're a family" line I got when people tried to get me on as a FT employee. I don't know about you, but it is usually true--and they have all the problems that families have too. They can keep them ;-)

Re:Deadlines

[Ponty]

Just this morning, I write a backdoor into a web project. Very often the testing users give me really strange errors that I just can't verify at all. It's useful to have a "master password" that I'll disable later (probably.) Backdoors are most often used for debugging purposes. Fortunately for the users, I'll be the sysadmin when the system goes live, so there isn't much of a risk (yet.)

Spyware

[GrumpyGeek]

I have never been asked to write a back door, but I have been asked write code to covertly send us reports about how the customer is using our software. The motovation behind this is that our software (Health Care) is price based on the 'number of lives' covered by our system.

My response was that I could do this, but that I thought that doing this without notfying the customer that it was being done was wrong. Stangely enough they did not argue with me, and as far as I know it has not been done.

Re:Deadlines

[quadcitytj]

In my opinion, this is a terrible way to build the system, and "debugging" methods like this are the reason so much code sucks.

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.

It's like installing an app, and then testing it as root. It doesn't tell you anything, and it makes user's lives miserable when they can't get something to work.

Backdoor in College Loan management software

[wawannem]

Here is something to think about, at my last job, we ran a very popular piece of software that is used to track and manage student loans for our financial aid department. One of our financial aid reps was having problems with her peecee and I sent out one of our IT support guys who was a full time student and part-time employee. He ended up calling the support desk for the piece of software in question and the rep gave him a backdoor account that was full access right over the phone. Luckily for me, the kid was honest and came back and told us about it. We all had a laugh that such an important piece of software could be compromised so easily and the support rep didn't even think twice about giving info on the backdoor to a student. Just to be safe, I periodically checked that student's account and made sure no phony changes were made. The more I thought about it, the more paranoid I became. I talked to my boss (the IT Director at the college) and found out that we really didn't have any choice in the matter, that piece of software was the only one like it. Thankfully, I don't work there any more, and I don't think the problem was ever exploited, but I wouldn't be surprised if I ever read about it. I won't divulge the information about the backdoor, but I will say that the software in question is called WhizKid and there may be college employees here on Slashdot that are familiar with it.

Re:Microsoft believes in them..

[kakos]

The NSA, interestingly enough, measures their computing power in acres. Yes, not Megahertz or flops or anything lik e that. They measure their computing power in terms of how many acres of computers they have. I think the current value is several thousand acres of computing power.

Job Security (was Re: Deadlines)

[DaTreeBear]

I saw first hand how back dooring software could provide job security for one developer.

I worked at a company that produced some very complex financial and utilities management software. They needed a way to have these two applications talk to each other and their solution was a daemon to act as a conduit between the two. Since it had to assume user privs the daemon was set to run root suid.

The code had been in production for quite some time when it was assigned to developer to maintain. The code was a mess (it had been written originally by people unfamiliar with programming in the Un*x environment). The developer was tasked with cleaning up the code if he could. Since they were very busy there was little or no supervision over him. As long as the daemon worked everyone was happy.

Eventually the development department decided to restructure and investigated letting this guy go. He had a reputation of being a bit of a hacker so they came to me (I being the Un*x/Network admin at the time) to see how we might protect ourselves from reprisals should he be let go.

I was fairly confident that my systems were tight. The biggest weakness as I saw it was this daemon. So I checked out the source code and started going through it. As I did, I discovered that this simple daemon had developed some new and interesting features. Along with it's normal duties, it also doubled as a telnet daemon (you could telnet to the listening port and login just as in telnet - except this one would ignore /etc/securetty thus allowing remote root logins over an unencrypted protocol). Another feature was it's ability to tunnel other ports through it's own listening port.

The code was too convoluted for me to get a complete grasp on it in the time alloted. I went back to the VP of development, pointed out what I had found, and suggested that he would need to have every piece of code this guy had worked on audited to make sure it was clear of back doors. He visibly paled. The developer in question had been there for over 5 years by this point and had touched nearly everything at one time or another.

In the end they simply moved him to another department (he is still there as far as I know). They felt it was too cost prohibitive (and dangerous) to let him go.

They never did tell their customers about these gaping security holes either.

Lessons learned:

1. Never trust code you haven't audited yourself. I had a daemon running on my servers that was allowing remote root logins and I didn't even know it.
2. A lack of integrity can be rewarding.
3. Customers are WAY too trusting of vendors.

Re:Deadlines

[capnjack41]

someone just has to look through the executable for strings.

For this reason, if I write in backdoors like that in a PHP script (a single admin password, for example), I don't actually store the password in a database or the script plaintext, I use an MD5 hash. Even if someone somehow manages to see it (they shouldn't anyway), it's still hard for them to guess what the password is (which they need to POST to the script).