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?"
I don't know about you guys, but not too many of my projects spare enough time in the project timeline to allow me to write backdoors or Easter eggs or whatever.
The last thing I'm thinking about when rushing towards the deadline is some fancy backdoor into a web app I'll probably never use anyway.
-- jimmycarter
Writing a back door is just more coding. Code for a while and see how much extraneous crap you write just for kicks.
this has been one of the biggest arguements towards using open source software. companies can theoretically trust open source software because everyone sees the code and they can easily modify it. my question is though, even though we have the source, do people actually read the thousands and thousands of lines of code in the program they're using or just the parts that would interest them (for modifying/improvement purposes)?
I (like many of you) work on a contract basis per project, and I'm contracted to fix any problems with the software as part of the job.
If an intruder breaks into a database through a back door I put in (and let's face it, it is asking for trouble), I'm obliged to spend my valuable time closing the hole.
I'm not of the opinion that it's worth my time and money to show off what a great hacker I am - my clients are really the ones who matter, since they pay my wages, and my skills should be reflected in my work...
sig:- (wit >= sarcasm)
This thread that gotten me wondering, what sort of legal options would one have should they find an employee coding in backdoors?
Would this be considered felony fraud? The more I think about it, the more I hope so. Think about this -- one coder acting alone could cost a company millions of dollars in lost profit and trust. This would be more than that coder will probably earn in normal income thruout his entire life. I think this is one case where a jury SHOULD seriously consider decades of imprisonment. This isn't a simple case of a kid using DeCSS or defacing a website, this is case of one person destroying the image and trust of an entire company.
The only way to guarantee that this doesn't occur is thorough code reviews.
Sorta, the only way to guarantee is to make ALL _checked_in_code_ reviewed. This is generally not a very practical alternative in any project that has real deadlines. What happens during a "code review" (a formal one anyway). People review the code, make comments and the developer(s) go off and make whatever changes. Ooops, gotta now review the code they changed.
Most applications have some sort of back door.
There are different extents to back doors. For example, in some filtering programs, you get admin access. In other programs, you have the ability to log in as a remote user. In another, you can bypass the encrytion passcodes.
Having a remote access backdoor saves lots of trips to a customer site. Having a backdoor for admin access is good when they lose their passwords. Or remotely shutting down the application is good when they don't pay.
There is also the other site to consider, if there is a back door, the application is clearly less secure.
You have to balance the lack of security caused by this by the need for the features the different back doors offer.
You should tell the client about this, but then it is a problem. If you tell people about back doors, some people may try to hack it. Having the remote ability to shut down an application may defeat the purpose.
Fight Spammers!
If you designed a system that you personally can break into, then you didn't put enough thought into the security design.
I personally think it's my responsibility to AT LEAST make sure that I couldn't break into the systems that I build without having knowledge of the passwords or whatever. If I think of a way that I could get in without it, I fix it or contact the person currently responsible for the code and let them know about it and how I think it should be fixed.
it was a variable name for a public key, not a backdoor or anything like that.
I would like you to go perform a simple experiment.
Write a "Hello World" program, where you have a static character array named "Fred" containing the string "Hello World" which you pass to printf.
Compile it.
Now, search the executable for "Hello World". You find it, right? Now search for "Fred". Funny, you get no matches. Doesn't that seem odd, considering MS's claim?
Doesn't it also seem odd that, in the context in which "NSAKey" existed, it fit perfectly in a data area containing identically-formatted key data?
read bruce schenier's column on it
Okay. Does the following quote sound familiar?
"Two, that it is actually an NSA key. If the NSA is going to use Microsoft products for classified traffic, they're going to install their own cryptography. They're not going to want to show it to anyone, not even Microsoft. They are going to want to sign their own modules. So the backup key could also be an NSA internal key, so that they could install strong cryptography on Microsoft products for their own internal use."
It would appear that Bruce did NOT claim the key only existed as a coincidence... He said it *might* result as a coincidence, or it might result from the NSA wanting to *improve* the available security for their own use (and, presumeably, to hell with the win95-using masses who fund the NSA through taxes). These do not describe the same situation.
Arguably, though, the "improved" security argument seems no less offensive to the privacy-minded. Why? Becuse, if the NSA saw a need to use super-secret-spiffy encryption for their *own* traffic, they did so due to the inherent weakness of the default crypto available (which I doubt many people would disagree with in hindsight).
So they didn't *need* a backdoor for everyone else, they needed a *lock* on the wide-open-barn-door for their own use.
not put backdoors in the software they create. I look at this way, give the client what they want and don't worry about anything else.
Why open yourself up to potentially losing a client or just looking like an asshole just so you can do something that your client probably doesn't want you to do.
What happens when someone else find your back door and exploits it? What do you tell your client when they ask you about why there is a back door into their application?
It is quite possible that you will get sued. Aside from losing your business you will lose any integrity and should be ashamed of yourself for disrespecting your profession.
Good programmers are ethical and do what they are told.
LoRider
1st, when I leave a company that I don't like or a company harms me - I consider that their "punishment" is not having the best man for the job - a backdoor would nullify this high ground and proove that I wasn't the best man for the job. And if a company is good to me, or I like them - than these are the last people in the world I would want to harm or compromize - so either way, it's just plain a poor way of living.
2nd, I don't know about you, but I worked on more than my fair share of projects where I could tell that the core was written badly, but didn't have the time, resources, or approval to do it the right way myself. There are plenty of things that could go wrong that I can get blamed for even if I do everything right, the last thing I want to do is add something else that can go wrong. No thanks!
3rd, I want denyability. When I leave a company, I want them to change the passwords, delete accounts, and for the code to be secure. The last thing I want is some breakin or failure put back on me years after the fact. There are plenty of shortcommings in life that can "catch up" with you, even if you do your darndest to be perfict. The last thing in the world I want to do is add some more to that pile.
4th, I rely on these people for contacts, reference, and refferals. Why risk burning bridges when I don't half too. Why risk a job when if I don't want it I am free to quit. If you don't like a company, why risk going to jail for them. If I must risk going to jail, I would much rather it be for a cause I believe in like that lady who refused to go to the back of the bus.
Wouldn't the better option be to make your application expire a certain number of days after installation UNLESS a code is entered? The theory being that when you recive payment, you provide the code.
The outcome for you is the same. If you don't get paid, the system locks them out. The outcome for the client is that honest, paying clients don't have hidden (exploitable) backdoors living in their deployed system.
Most of these comments do not particularly apply to "the web" as, in my mind, a web browser is just another interface surface (like a printer or a live screen) and the IO parts of a program are only the surface.
During the construction of a program I almost always end up writing a test harness for each significant module. Where possible I like to include the test harness inside the library for that module.
I then, when assembling the final product, do compile time control of whether the target application does, or does not, have the hooks to branch into the test harnesses. When an application ehxibits an error that doesn't have a clear source origin I switch to the "debugging version" of a product and that brings in a fully-featured set of back doors and hacks. Clearly the dubugging version is not suitable for production.
That having been said.
A certian lazyness on the part of the developers combined with a sloppy mind set being promulgated by the "I can drag and I can drop so I am a programmer" school of language-constructors, debuggers, and IDEs, has led to a plague of escaped code.
A primary example of these escapes are "cheat codes" in games. Now days, you can't even expect to sell a game at all unless it is rife with cehat codes you can include in the book. These are the "send a message to all from the console saying "I Am Rich" and you will get $100,000 credits at the start of your next (event)" things. They clearly exist so that the developers can go in and exercise the extreme limits of their design but then they are never disabled later for the production release.
This is dumb and annoying in games. In "real" applications this is potentially catostrophic.
But the "whats good for bob is goog dor ted" mentality causes the cheating haxor kiddies, who have seen these back channels as required parts of every program they have used growing up (e.g. the games) and now somehow think such things *BELONG* in code.
Any culture that teaches kids to just use the cheats (the cheat codes are even commonly printed in the manuals now, and then *explained* in detail in the walkthrough & cheat book you can buy seperately) and that any program without those cheats is probably trash, should not be surprised that when those kids enter the workforce they will, as a matter of self-pride include such things in the code they then write.
(Example: my room mate is 12 years younger than I. He can't function in a game, or at least "can't enjoy" a game, unless he has got the FAQ and walkthrough around "just in case." What has he learned from life about "working it out himself?" and what should that teach the rest of us?)
Test harnesses are necessary for development.
They should be expunged from production code.
Programmers should *know* *how* to write code that doesn't change core behavior when you take out the test harnesses.
Games and toys should not be an exception as that sets bad habbits.
===
We are all doomed...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Would you feel better if it was a radio button or or slider rather than a clickable button? Also, it is about as malacious as Winamp, in that you have to allow it to phone home, and you can choose to allow it to report anonymous statistics (just like winamp). I don't see people with pitchforks calling for nullsoft's (er... AOL i guess) heads.
Doubtful. A backdoor is never needed. There's no backdoor to losing the Administrator password on an NT box, yet you can reset it with physical access. Would people be thankfull if there was one? I doubt it, you'd probably have an ape shit.
You are the epitomy of what is wrong with many developers today. You hate your users with a passion much like some land owner has towards his 'peasant' workers. Grow up, listen to your users, respect them and advise them, and with all honesty work towards middle ground.
-malakai
-Malakai
A Dragon Lives in my Garage