Do You Write Backdoors? 1004
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 backdoor all the time.. (Score:5, Interesting)
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. (Score:5, Interesting)
Default passwords are as good as a backdoor (Score:5, Interesting)
Out of curiosity, from a personal machine, I tried logging in to as administrator to a few of these machines with the default password our product shipped with. It worked about half the time.
(Of course, one can't take the results of my search as suggesting that half of our customers didn't change their passwords, as the fact that these people hadn't updated the web image makes the fact that they didn't update the admin password wither not so surprising.)
Almost Every One. (Score:1, Interesting)
Payment Insurance (Score:5, Interesting)
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.
Backdoor? (Score:5, Interesting)
Its like that theory that BAE
Unlikely, but interesting concept all the same!
trust... (Score:5, Interesting)
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 (Score:5, Interesting)
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... (Score:5, Interesting)
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.
Hire developers directly (Score:4, Interesting)
Maybe a good idea would be to bring on a full time development staff and pay them good money so they don't feel the need to try to get something more. Oh, and tell me where to send my resume once you create these new full time positions.
Not such a good insurance policy (Score:2, Interesting)
PHP Web-apps (Score:5, Interesting)
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.
Re:I backdoor all the time.. (Score:1, Interesting)
Are you implying there is a 'backdoor' account in all copies of Windows?
???
Sure... (Score:4, Interesting)
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 (Score:5, Interesting)
Doing things like
Anyways, my point is that most backdoors put in by developers seem to be accidental rather than intentional.
winxp? (Score:2, Interesting)
I worked with a guy... (Score:2, Interesting)
I personally considered this to be very unprofessional, and probably not legal, but he claimed that it was perfectly legit. Of course, the client didn't know this, and he never told them (they did pay their invoices on time).
Definitely not my style, but it is evidence to me that it is done on a regular basis.
consequences (Score:5, Interesting)
Re:kind of... (Score:3, Interesting)
That some Jr. programmer 5 years from now doesn't
forget to turn off the backdoor?
Re:Microsoft believes in them.. (Score:5, Interesting)
Back Doors.. (Score:3, Interesting)
I think you really have to consider the intent. If someone tries to go into the code and deliberately put a back door in w/o proper decision authority, that should be considered unethical. If the client wants it tighter than Fort Knox and loses the key, it's not your fault.
Re:Open source, of course (Score:5, Interesting)
Having the source available isn't necessarily as much help as you might think. Since nobody else has mentioned it yet, I suppose I'd better do the honors and point y'all to Ken Thompson's classic talk on backdoors, Reflections on Trusting Trust [acm.org].
Highly recommended. It's a good reminder of just how devious it's possible to be.
Make sure you get paid. (Score:4, Interesting)
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.)
Backdoor? Nah, Easter egg (Score:2, Interesting)
However, I've been involved in projects where we've added an easter egg.
Why? I don't know, it's fun, easy and it's cool when you can show someone that you actually was part of the development. Ofcourse, these projects were inhouse product development. I would probably not consider doing such a thing in a customer's product that I'm working with, besides, that's not what they are paying me for.
For professional use only (Score:1, Interesting)
backdoor root access (Score:3, Interesting)
The program came in handy a few times. I finally deleted it about six months later.
the short answer (Score:5, Interesting)
MS Easter Eggs (Score:4, Interesting)
Does an exploit count? (Score:2, Interesting)
As a result of this, anyone who knew our software could get in as root to any of the servers running our billing software. I haven't worked for that company in 4 years, and I don't even think they are still around, but anyone running that billing software can be compromised (hopefully no one is still using it, but you never know).
We did have a standard user that we setup in the database as well, so we could perform maintenance, but we told them about it, and coordinated maintenance with them. That could be contrived as a back door as well though, as it did allow remote access by our company.
Re:the short answer (Score:3, Interesting)
On the other hand, some security vulnerabilities could be carefully engineered or intentionally neglected by a malicious developer. Written carefully enough they could even look like an honest mistake... like the latest buffer-overflow in Sendmail for example?
Then I suppose the incentive comes into play.
Time to become a contractor! (Score:5, Interesting)
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 (Score:5, Interesting)
In a previous life (Score:4, Interesting)
Savvier customers changed the username and password (the rule required the user_id entry to stay in the db. But you could change the username/pass to keep undesirables out of the system. Yet many of the customers didn't ever even officially "discover" it... Before I left I never heard of any malicious things being done with this account, but as I told my boss the day I found out about it, "Its only a matter of time."
I left when everybody around me started getting ".com" fever. Like, wacky. People who made $50k annually were leveraging a fortune in paper stock options to buy brand new Mercedes Benzes and hot tubs...
Re:Backdoors are nice but.... (Score:3, Interesting)
the facts are:
As to giving the customers the source code, I remember doing that in the mid-'90s before it was fashionable, and having their "computer people" continuously removing it from corporate systems because it wasn't on the "list of approved programs".
One of the first back doors (Score:4, Interesting)
Re:the short answer (Score:3, Interesting)
Product X has a backdoor. Product X is released as open source. A few vigilant hackers start pouring over it ASAP and find the backdoor and exploit it until it's found by someone in the good community. (Maybe a full year later, as you said.)
Just food for thought.
Re:Payment Insurance (Score:5, Interesting)
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 (Score:3, Interesting)
Um... Duh?
Someone who did this to you would not have gotten paid. Thus, I have very little doubt that they would *NOT* work for you ever again, but that would result from *THEIR* choice, not yours. People do not generally like to work without getting paid.
"Aww, c'mon man, PLEASE let me spend another six months coding for you, only to have the check bounce!"
Video Games (Score:2, Interesting)
- Codes we share amongst ourselves (dev team and with the testers) get out. This is obvious.
- Some codes that I do not share amongst the team got out. And these are complicated as HELL. Like doing a series of things in the game and it having another effect minutes later that you must also know to activate. I show just a few people that these things are even possible, without sharing how. (Yes it's fun to feel cool.)
- Some codes that others added that I do not know about show up in public.
Conclusions: No backdoor is safe. Once released (or delivered), the code is in the hands of the enemy. Period.Corollary: People have way more time on their hands than they should.
Re:the short answer (Score:3, Interesting)
But who thinks about the long term these days? Even the richest people in this country are committing all sorts of fraud for a quick buck.
Re:Of course (Score:3, Interesting)
Re:Backdoor? (Score:2, Interesting)
Very simple for legal recourse (Score:3, Interesting)
It's responsibility...
But then again this country's general populace doesn't accept the concept of responsibility... Just look at the number of stupid lawsuits that are out there and the number of criminals that have gotten off with a good lawyer...
my 2 cents
Re:I backdoor all the time.. (Score:3, Interesting)
SQL injection is mucho phun too! (Score:5, Interesting)
Security is much more likely breached through some SQL injection exploit than through default passwords. Don't believe me? Just go to a random smalltime e-commerce site. Watch you browser's title bar. If you see an URL of the form http://server.com/some/directory/path.asp?param1=v alue1¶m2=value, then try sneaking some quote character into one of the values in the URL. More often than not, you'll be greated with a Sequelserver or Access error message. A smart user can figure out from the error message which kind of database query the app used, and he can sneak in characters that will yield useful results...
If the database engine is Sequelserver, the attacker will try reading out the sysobjects and syscolumns table to figure out the schema, and from there he may harvest credit card numbers, names, addresses, or just play random pranks with the stored data.
If on the other hand, the database engine is Access, it's a tad more difficult (because in Access, the msysobjects table is by default protected, and its error messages contain less useful info too). In that case, you need to find the URL that allows administrative login (often called admin.asp, admin_login.asp or somesuch). And then just type '='' or 1=1 or ' into the login field, and you're in.
This works especially well against fly-by-night operations such as those advertised by spammers. Often spammers' remove-me links are vulnerable too (if you see .asp? in the remove-me URL, chances are that you can have some fun with it...). Great revenge tool if you get too much spam, or if you simply are bored!
Re:Sure... (Score:2, Interesting)
One word: liability (Score:3, Interesting)
Obviously you take the risk to get fired on the spot. But of far greater risk is your liability. What if your backdoor causes (unexpected) damage to the company? Do you have the pockets to make up for that? Because you can rest assured they will be knocking at your (front) door.
If you have to write a backdoor for 'good' reasons, make sure the company is aware of it, and there should be no problems at all.
The 'putting in a backdoor to make sure a customer pays in time' is stupid as well. If someone writes software for me and comes back with an 'update' after we pay that removes a backdoor, that was exactly the last time that person would work for me.
In fact, that programmer would have signed a contract that specifically states that we do not allow backdoors, but I guess not all companies think of that... Regardless, that programmer has wasted the company's time, with all sorts of (legal) consequences.
Re:Deadlines (Score:5, Interesting)
Doing this right now... (Score:2, Interesting)
Remote Code Hosting [jmagar.com]
not, a backdoor, but a timeout (Score:3, Interesting)
I was at least a little clever in how I put it in; didn't make the check too obvious. But our source control system gave me away (I knew it would, but I wasn't trying to be that secure). I've wondered though, how difficult it would be to plant the change in a much older version of the source file. We were using SourceSafe, but I've never looked into the format of the actual files or how that would be done.
Spyware (Score:4, Interesting)
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:possible legal actions? (Score:1, Interesting)
http://www.harktheherald.com/article.php?sid=7394
Re:Deadlines (Score:5, Interesting)
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.
Re:the short answer (Score:2, Interesting)
I guess you are referring to Interbase [ibphoenix.com] here.
IIRC the 'backdoor' was rarely changed default system password. This combined with bootstrap caused some interesting behaviour forming a backdoor.
In Interbase a seperate database schema is used to store database username and password pairs, unfortunely you can't access that until you are authenticated, so a backdoor was added so get round this problem.
BTW, this is all from memory so check the archives before taking what i've said as gospel.
Re:Backdoor? (Score:1, Interesting)
Backdoor in College Loan management software (Score:4, Interesting)
I kinda did this... (Score:3, Interesting)
Paranoid that the minute I gave them the program it was going to turn into "Mooman? We never heard of no Mooman" and screw me from the sales, I made a backdoor/easter egg: While the splash screen was showing, if you type m-o-o, the splash would change to information about my little company.
Since the people I was providing the code to weren't Delphi folks, I figured it was a safe CYA to make sure that I got credit where it was due...
I also wrote a perl-based self-registration CGI for them too, and in it I set up a backdoor just so I could get the count of the number of registrations.. Again, just to keep 'em honest.
Not malicious by any stretch but I feel completely justified in what I did...
Re:Payment Insurance (Score:3, Interesting)
Re:Deadlines (Score:3, Interesting)
I carry around all sorts of hacks and backdoors for the software project I work on. Toggle the hidden switch and bingo! You get access to parts of the code that require a different license. Helps me to debug things (extra state analysis routines) and I don't have to get the customer a temporary license.
Re:Deadlines (Score:2, Interesting)
I mostly have worked on embedded systems. One of them typically didn't have a keyboard installed, but did have a standard PS/2 keyboard port hidden on the back. Pressing any KEY on that would get you past any password prompt on the front interface (LCD/Membrane 10-key pad.)
On another system, a POS system, there's a master password that changes daily, based on a date calculation.
Both of these are used for support purposes, though. On the POS system, there are some changes that can only be made using the "master" login and password. On the controller, field techs use it to reset a password after the owner of the system has lost or forgotten it.
Backdoors bad... Easter Eggs good?? (Score:2, Interesting)
But, on the other hand, I have build Easter Eggs into systems I've written. One system that is used by thousands of users at my current employer has a silly little Snake game in DHTML if you find it, another high-volume system has Blackjack built-in.
Neither has ever been found, but I have told a number of people, including the managers that sponsored the projects, about them (after the systems were deployed). They didn't seem to mind too much (looked at me kind of funny, but didn't really bitch).
The question... is THAT ok? I know probably most big-time sofware has eggs, but as a matter of course, should it be acceptable, or is it generally unacceptable like back doors seem to be, judging by the general tone of the responses here?
Many of the same arguments apply, such as extra code that could break and put blame on you... They might even be exploitable as security risks if really pooly written... And of course, it most probably was NOT in the client's requirements, so should you do it, even if your intention is not nefarious (mine certainly weren't).
I don't know, I'm kind of torn now that I think about it. I've done it before and didn't think twice, not so sure I would in the future though. Thoughts?
Re:Backdoor? (Score:4, Interesting)
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.
Re:Deadlines (Score:2, Interesting)
So true!
Seriously, unless the coder in question is devious, lazy, or has personal motives... they are most likely busy working on getting the production code to work.
The last thing you need is to debug a problem only to find out that the "special something something" is what was causing the problem because you didn't code your special access correctly.
Now, disgruntled employees or those who feel the world are constantly against them, who feel that they have been slighted and WANTS to get back at someone or something to even out some score... they will find ample time to make more than just back doors regardless of their workload. Who needs sleep when revenge is just beyond the next subroutine?
As always, a good working relationship and strong trust going both ways between co-workers and management is key. Without that, backdoors would be the least of your worries.
There are legitimate uses for back doors (Score:3, Interesting)
So, we created a method whereby an administrator could log in as any non-administrator user by supplying the non-admin username and using their own admin password (on a page separate to the normal page). No global master password. One-way encryption of passwords.
When someone logged in this way it was logged to the database that the customer was being spoofed (and by whom) - audit trail. Once the login check had passed the admin could act as if they were that user.
This was considerably more secure for the customer than asking for the customer's password and telling them to "change it later" (which was what we'd had to do previously).
This became an official feature of the app - albeit a not-very-well-known one. To use it you had to have superuser access - which usually meant that you had direct access to the back-end database anyway.
This reduced the time required to deal with problems by a massive amount.
Re:Microsoft believes in them.. (Score:5, Interesting)
Telco eastern egg (Score:2, Interesting)
Perre was here!
(his name was Per, Perre is slang). He was sent to the boss and he had to take it away. But I actually think this code got out to customers. If Per reads this you might wanna fill in what really happend at Ludde's office.
Re:Payment Insurance (Score:5, Interesting)
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.
Re:Deadlines (Score:5, Interesting)
Please note - this link is to a theoretical discussion of how the first UNIX creators could have installed a very-hard-to-detect backdoor.
They never actually did this.
Anyway, this simple example wouldn't work, for two reasons:
1) It would leave lots of evidence behind in the log files - someone, somewhere, would eventually notice.
2) Not *every* c compiler was compiled by a cross compiler, creating an uninterrupted chain back to the original C compiler written at Bell Labs. A number of platforms were built from scratch, using bootstrap compilers rather than cross compilers.
Clever, though.
Wrong (Score:0, Interesting)
RMN
~~~
Job Security (was Re: Deadlines) (Score:5, Interesting)
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:
It's all about quality of life, man (Score:4, Interesting)
What my friend meant was that it usually takes a good amount of bitterness to make anyone consider contracting. It's a scary step and most are intimidated by their manager's comments about "contractors have no benefits".
That's all it meant--i.e. "perhaps you are now bitter enough to take a risk". But what you said still applies. I had many friends who were bitter enough to give it a try. Only one friend of mine did and is still doing it.
My comment was the same thing: if you feel that betrayed, realize there are other options.
As for me, I did it because I was fed up with flushing my life down the drain in salaried positions. When I get paid by the hour, I find I get more equitable treatment. Employers *think* about what they want me to work on. And usually they are more serious--since my time equals money in a very easy to use formula. And I don't feel like I am being cheated when I get a heavy work load--more hours equals more compensation.
Less pay or not, salary is for suckers. Even if contracting is making half the money, right now pay is down across the board and salaried employees are being asked to work twice the hours. So do the math.
(OTOH, during the dotcom days, I made some serious money. Ah, things will never be like that again *g*)
For me, contracting is about quality of life--as in, I have one now.
voting (Score:2, Interesting)
But, it's just so gosh darn conveninet to have the computer vote for me! And it's so modern and techy trendy! And "they" wouldn't do anything to affect a vote would they? I mean it's not like anything as important as control of a state or the world's most powerful country is actually enough motive and incentive for the nice people at E-VOTIN'TECH.con Inc. to do naughty things, is it?
Nawww-never happen in a billyun years, people are all honest, rilly and trully!
Re:Payment Insurance (Score:3, Interesting)
In construction it is a very common thing to not be paid by your general contractor due to cascading bankruptcies. I have seen many contractors take different precausions against not getting paid, of which I found this one particularly clever. It's possible it's not a legend at all and does stem back to to the 30's and 40's or even before since the practice is very easy and cheap for a mason to perform, requiring only about a 10"x10" thin sheet of glass and about 15 seconds of installation time; about the same cost and time that accompanies laying a couple brick ties.
Needless to say (not trying to convince you of the legend, as both I and you are random internet entities that could care less what each other think) but that's the first urban legend I ever saw practiced
Re:Deadlines (Score:2, Interesting)
I have had situations where code runs fine on the development box but when it is copied to the (supposedly) identically configured production box things fall over. I don't have login access to the production box so I have a backdoor that allows me terminal access for debuggin purposes. Without this bugs that currently take me 5 minutes to find would take someone else sever hours of sorthing through httpd.config files and trying to see what diference is breaking my code.
Re:Deadlines (Score:2, Interesting)
someone just has to look through the executable for strings.
Oh my... looks like you never wrote something remotely similar to a backdoor. And I mean no just-for-debugging-and-then-i-remove-it backdoor, I mean a real one. A backdoor that's meant to be misused. E.g. you are writing some software for your bank ;) That kind of backdoor. The first rule is that the backdoor should be as invisible as it is possible. And some strange password-like string is the simplest way of shouting "hey, I'm here!"
A real backdoor should look e.g. like the one legendary that once was in a C compiler... for more info see the jargon file entry on backdoor [watson-net.com].
Re: Do You Write Backdoors? (Score:2, Interesting)
Why? Because I REALLY do not like to lose. If I ever got screwed by a client, they would stand to lose more than me.
Have I ever USED one of my backdoors? Only once in over 24 years of working with computers. I wrote a program for a college professor who then turned around, changed the opening banner/credits/logon page to HIS name, and then sold it to the college as his own work. I went in, changed the page back, blew away the user and password file, and disabled the logon sequence. Everyone on the college's staff who had a computer got to see what I said about him the next morning when they tried to log on.
A few weeks later, after all the shit was through flying, I gave the college the program for free. Along with the source code (Open source circa 1979!).
Re:Deadlines (Score:5, Interesting)
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).
Re:Deadlines (Score:1, Interesting)
Required Backdoors (Score:2, Interesting)
The less sophisticated customers would never authorize anything like that until and unless they were in a panic, so we learned to pre-install it. In general, saving the customer from himself is necessary to maintain good customer relations, and is probably the origin of the term "Customer Engineering".
Re:Deadlines (Score:4, Interesting)
This is something I wish more systems had, but not in a hardcoded (backdoor) way. Cyrus SASL/IMAPd does it correctly: they've completely separated the concepts of authentication and authorization. So you can say "until further notice, user slamb can log in and do anything user bob can do." It serves the same purpose, but in a maintainable, open way. You can have a group of administrators that can log in as anyone, but without needing to know either everyone's password or some master password that's difficult to change if someone leaves...they can just use their own, and it can be disabled/enabled on a per-person easily.
This is a TRUE story. (Score:4, Interesting)
But I don't remember the guy's name. Or maybe it was a chick. But whoever it was, they were definitely a staid and steadfast compiler writer.
Re:the short answer (Score:3, Interesting)
Fortunately, in this case the flaw was noticed and corrected by a later developer.
Re:Job Security (was Re: Deadlines) (Score:1, Interesting)
it had been written originally by people unfamiliar with programming in the Un*x environment
What do you mean by unfamiliarity with environments? I am a windows programmer who write programs for Solaris as well. I haven't seen any difference in the implementation (except for the obvious win32 / POSIX differences). Please tell me more.
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.
Customers are WAY too trusting of vendors.
Web interface to SQL Server (Score:1, Interesting)
We asked for access to the machine so we could run simple SQL queries just to figure out WHY things were bugging when the reports started dropping in - but it was against the customer's security policies to allow us on the machine.
It all ended up with us coding a web page which simply was one form and a submit button. Into the form you could type any SQL query and it would be executed directly on the tables, and the result would be displayed in an HTML table on the page. The page was of course password protected and not linked to anywhere, but still...
This is possibly the worst case of security policies gone wrong I've ever seen, and fortunately also the only 'backdoor' I've ever coded.
Posting anonymously to protect the customer.