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?"
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.
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.
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.
Praying for the end of your wide-awake nightmare.
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...
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.
http://kered.org
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.
Doing things like
Anyways, my point is that most backdoors put in by developers seem to be accidental rather than intentional.
C - A language that combines the speed of assembly with the ease of use of assembly.
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.
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.
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: