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
Unless he was acting on some sort of order from you or someone else who can tell him to add something like that, I'd fire him.
I'd also look into opening a criminal investigation.
i believe that our god friend bill had once added a back dor password "netscape users are weenies"
I've never coded backdoors into any software I've written. I usually don't use them in the future, and if I really need them, I gain access by other means. I can't see a logical reason to add them in, especially if you're job depends on the integrity of your code.
I don't really think this is an appropriate Slashdot topic. Bedroom activities are an intensely personal - oh, sorry. Write backdoors. Never mind.
i thought the hbackdoor was the onlydoor...
since when is there a front door
Writing a back door is just more coding. Code for a while and see how much extraneous crap you write just for kicks.
Yikes... This subject is just asking for a goat link!
No way am I clicking on ANYTHING!
my code is so tight, the front door and backdoor are on the same hinge! hooah!
Only in the BBS Software, did I write backdoors, those kids never registered...had to slap their hands a bit.
Well are ya?
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.
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)?
you develop applications and don't get server access? if that is the case, the client certainly does not want you on the server. hence they wouldn't be too happy about your backdoor....
Guess, that with tons of lines and hundred of coders, there must have backdoors !
Have they ?
-SLK
fucky fucky!
The only way to guarantee that this doesn't occur is thorough code reviews. The argument that the project is too large or complex simply doesn't hold water; the larger or more complex a component gets, the more carefully it should be reviewed.
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.
Maybe some companies have 2 sets of programmers. One to write the code. The other one to inspect it. Gotta trust your programmers sometime along the line I guess. For if you can't trust em, why did you hire them? And yeah this is the first post, yay :)
Here's a list of 1090 backdoors.
"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."
/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.
Its like that theory that BAE
Unlikely, but interesting concept all the same!
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...
Never wrote any backdoors per se. The closest was an ISAPI web app that needed to have certain users set up in order to work. I created the users in the installation application and later added an administrative user that was supposed to be created by the web master. Well, the web master didn't always keep up with this on new machines, so I just added it to the installation program (with approval).
That was years ago, but I wouldn't be too surprised if the user was still in there somewhere.
To the making of books there is no end, so let's get started
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 ...
Easy:
1) Code reviews.
2) File change diffs emailed to developer mailing list.
3) Group-owned code.
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
Though it wasn't explicitely mentioned in the question, I feel that such a situation may be more common when the developers are hired as temporary / part-time help. In this case, you are a client and the developers may be looking to get something more. If you have your own in-house developers, they'll have more stake in the company and the project, and surely would care more about security - both the security of the software and the security of their job. A hired hand could code the backdoor then move on before you ever notice. Your own developers would be more hesitant to do this because if and when it gets noticed, they'll still be easily found in the cube on the third floor, east wing.
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.
How are you going to keep them down on the farm once they've seen Karl Hungus?
Backdoors can be a good insurance policy, and their theoretical presence might guarentee your continued employment, but if your employers find them, I can guarentee you won't be working there for much longer :P
If you mean "backdoor" as in a way for a tech support or other person to get into a system that can be eaisly screwed up by users, then there are many of them around. If you mean "backdoor" by a hole that only a single coder (or small group) of coders knows about so they can stroke their ego, then there are probably are fewer.
I imagine that this kind of thing happens more frequently in situations where the company doesn't treat its employees well.
A backdoor allows you to make changes and tweaks after the application (or site) goes live but they just aren't worth it. Especially if it ever dawns on the customer that you have made changes (such as a bug fix) without consulting them. If you need to change the software then you need to consult the customer. Period.
If the customer ever figures out that there is a back door or if it is abused by a third party, they will never hire you or your company again.
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.
And it lives here!
This story was just begging for this link!
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)
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
there is no reason for it, except to 'monkey around' behind the scenes, and that always ends up bad.
The Kruger Dunning explains most post on
{--- Insert obligatory Mr. PotatoHead comment here ---}
Comment removed based on user account deletion
There shouldn't any hard-coded trust between the authors of decent software and the buyers/users of that software. The fact is that any useful information that the backdoor could provide to the coder should be available to the purchaser. If the purchaser wants to trust the coder he needs to run sshd and give the coder and account with access to the application he coded. Why anyone would "reinvent" a secure backdoor when it can be accomplished with Freely available tools to a much greater level of security is just beyond me.
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.
Personally, I wouldn't, and I haven't even when presented with the opportunity. However, though I don't know for sure, I flatter myself my sense of ethics is slightly stronger than the average hacker's. I imagine it's a fairly common practice, actually ...
-- shayborg
ok, i don't think there's a backdoor, but i know windows xp comes installed with a special microsoft tech support user. how do they get to use that user to fix problems? that's what i don't understand. it's really odd i think. i wouldn't be surprised if microsoft started putting backdoors into their software that only closed when you entered a unique serial number that bounced back from an online serial number database. similar to the way Q3A uses the cd key. although i know there are some hacks to the Q3A cd key to allow you to use a pirated copy, so this may not work. i just wouldn't put it past microsoft to do something like that.
please me, have no regrets.
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.
I'd say that most slashdotters have "installed" someone's "backdoor" more than a few times.
It's all about design.
If programmers are told to make something work, and there is little design, the entire program is a black box, and not understood until it is looked at completely.
With proper design, the program is understood before it is coded, and the appropriate modules or sections can be looked at easily. Of course testing plays a significant role, but at this point design is far more important.
Unfortunately, most programmers don't want design (probably Ps) and most designers want too much control (probably Js). There needs to be a general respect for the other's gifts for everything to work, and have people want each other's help.
Have you read my journal today?
When I was a consultant at a Big 6 firm (back in the day), a colleague of mine wrote a Windows app for a client. He added code that would cause the application to stop working after a certain date, so that if the client doesn't pay their invoices, he won't update the code, and the app will simply stop working.
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.
Check out this backdoor to my backdoor
IMHO a company is foolish not to check their code to some extent before it is released, in which case these should be easy to spot.
This of course is a major advantage to open source, you can check for yourself if you are paranoid.
Ultimately though, i think programmers have to be trusted to some extent, and so it will be impossible to completely get rid of this kind of thing.
And keep track of all of them. So if they start to be exploited, bam, get in the backdoor and close them all.
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.
Speak truth to power.
And as a former employee, you give a shit why???
I'd like to post an intelligent responce, but I need more info. Can I have some people send me a list of back doors they've created so that I can investigate further? thanks
And password is always swordfish...
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
1) if it's not in the requirements, it shouldn't be in the code
2)if it's useful or necessary, then it should be in the requirements. But it's not a back door anymore (maybe a side door?)
It's supposed to be completely automatic, but actually you have to press this button.
never - unless required by contract.
And even then it's maximum security...
As sustainable as what was stated in the contractual relationship between the development company and the client. Backdoors, exploits etc, should not be allowed unless explicitly requested by the client. These 'Backdoors' - however innocent - could be the cause of a financially burdensome exploit at a later date, which I'm sure the client would not appreciate.
This area of functionality is definitely something which should be highlighted as part of the Master Service Agreement or within the Statement of Work. Within your own development team, your team members should understand the implications of introducing such code into clients' projects.
[Disclaimer: I am not an attorney. For legal advice, consult one!]
Putting backdoors is unethical, but possibly not illegal depending upon how you make your software available (i.e. license terms and conditions). It may only be illegal where you _use_ the backdoor (because you are then technically trespassing on property of another), or if someone else uses the backdoor (you could be held in negligence).
I've been involved in a project where an easter egg was planted (command line interface to a subsystem, and if you enter right command, it will drop into a text RPG). You could get in trouble for this in certain ways:
(a) wasting client money (if the program developed under contract and this functionality is outside of the scope of the development agreement);
(b) negligence/action if something goes wrong with the functionality or leads to lack of performance of the software, etc.
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!
Remember the backdoor that Cott Lang (AtomicPunk) coded into the popular Renegade BBS system? I wonder if he will ever live that down!
The issue of a programmer's moral fallibility is something that comes up quite often here at work. Being in a borderline staff/management position, I've been forced to look at the situation from both angles. I also know that any efforts from management to dissuade these lines of "malicious" code will either piss off the programmer or indicate that you don't trust them, which will in turn, ALSO piss off the programmer. Briefly, we do have a stage in the process of "FINAL CODE ANALYSIS" where basically programmers from different departments are pitted against each other in an effort to find faults and potential security holes in each other's code. Regardless of these measures or any additional steps you could take for that matter, it comes down to one of the sole elements of human nature: TRUST.
I personally backdoor quite often.
Like one of the posters above, I do it purely as a security measure. Very rarely do any of the programs I write contain data that I'm interested in once given to the end user, and thus I have no reason to want access to it except for their own benefit.
By the same token, I have refused backdoors requested by other people (usually in the form of emails or messages when certain actions occurred) because I didn't want to feel morally responsible for what they might do with that information.
Backdoor is a really broad way to describe what is, very often, a time-saver or even security measure. I personally wouldn't build one with malicious intent, but I can see where it could be a problem...we install programs every day (windows environment) that we have no idea who wrote, and what motives they may have had.
Didn't we learn - if your developer is complaining that he doesn't get paid enough, you'll have dinosaurs eating your customers soon enough?
How sustainable is the 'trust' between the developer and the client?
I really hate to say this but lawsuits are the answer. Have something in the contract that specifies backdoors will result in forfeiture of all pay, developer liable for repairs, developer liable for legal fees, etc.
Now for an even more controversial point. Make sure the developer is reachable and has something to lose. House, car, etc. In other words the open source style virtual organization spread around the world may make you more vulnerable due to less accountability. I realize this is heresy around here but every development model has advantages and disadvantages, different tools for different jobs, different models for different jobs.
Seriously, this is why every line of code is *meant* to go through proper examination by your peers. With the number of eggs and backdoors in some commercial software (*cough Excel 97 *cough*), you have to wonder...
I'm a girl too! See naked chicks in my journal!
In my experience, back doors tend to be "in the mind of the programmer" as opposed to code that was physically made to be that way. It's not that the programmer sat there and added a way to hack in-- it's just the fact that since he knows how the system works, he knows how to gain access if need be. After all, just about everything electronic can be exploited at some point.
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.
Most companies elect to accept this risk, because otherwise they couldn't accomplish anything without people. You can mitigate the risk through performance contracts, background checks, adequate compensation and other measures, but you can never actually eliminate it.
In my opinion, trust is the issue at the core of Information Security. This is a difficult problem, and maybe one that will literally never be solved.
Check out my eclectic infosec blog at InfoSecPotpou
Yes, he wrote a backdoor into your spellchecker that makes you sounds like an illiterate retard whenever you write something. See? He did it again!
I have been developing software in some form or another ranging from ascii based games to multi-tier web applications, since I was 8. I'm now 30 and I can say without hesitation that even without explicitly coding a backdoor a "good" developer can get into and exploit a system of his/her own design and development simply as a result of an intimate understanding of the application and how it handles data. So the only way to really prevent this, if you were really that worried about it, would be to labotomize the developer or somehow wipe his/her memory. Cheers, Binary Air
Uh, no. As a matter of fact, a lot of us have more integrity than that. This reminds me of how liars always think everyone else is a liar too. In fact, sociopaths are a minority (whether or not they believe it).
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
If the audit group is independent of the development group, collusion is much less likely. If the audit group is actually a group (Not one person) collusion is much less likely. If the audit group has a stable job situation (IE: They're always getting new code to audit and don't have to worry about being laid off in a couple of months) collusion is much less likely.
I'd suggest considering criminal and civil legal action against the developer who wrote the backdoor. Pass it on to legal (You DO have a legal department, right?) and see how they feel about it. I bet they'll be happy to make his life a living hell for the next decade.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Does writing interesting code(tm) count? I used to work on distributed computing applications in strange and interesting fields that almost always required the following steps:
...
1. Drill hole through firewall.
2. Listen on port...
3. Connect
4. Run some highly unusual code written by Kevin* when the application requests it
In practice, almost all of the systems could be cracked in less than ten seconds by a deformed and brain dead hedgehog**, if the hedgehog knew what I knew about the system.
All the holes were documented, and minimised to the maximum extent possible. And no, I have not used the backdoors for any illegal purpose. But a lot of programmers write backdoors because they can't do otherwise; the application requires it.
* Kevin, our resident Moron of the time (all names have been changed to protect the idiots).
** Also known as Kevin.
"As a writer / novelist you might want to spellcheck your sig.
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.)
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
All the code I write has a backdoor of some sort, a suble buffer overflow, or just a plain shell somewhere :)
:D
BUT, to prove my integrity, all you have to do is remove -DHAVE_BACKDOOR from the Makefile
that start a project with planning the backdoor.
I dont beleive in them, and as such dont code them into anything i make. I dont have the time to write something into an app that i wont ever want to use, let alone want to administrate :)
On a side note, i do know that some hardware companies still practice little known backdoors and secret user accounts... IE Alteon Load Balancer Global ACCT that does exist, but works on every LB before a certain firmware version.
Backdoors are very hard to justify and also adds coding (as mentioned here before).
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.
I've never put an access-granting back door into an app, but i can certainly see the benefit of having them in certain situations. Most of the time i'd rather have to tell the client they are fucked and they need to reinstall rather than leave a potential security hole, but then the stuff i write is never that mission-critical.
(I have put in a semi-secret kill switch so that i can shut down an app rather than waiting for a sysadmin to do it for me. The sysadmins got pissed the first time i told them i had shut down the app, so now i just tell them it caught an error and shut down on its own to preserve data integrity.
They never actually check the log to see if it's true for the same reason that they don't give me a prompt shutdown when i ask for it - they don't care about my app or my work because my immediate boss isn't their immediate boss. They just don't want anyone doing something that is supposed to be their self-given right as root.)
The only thing necessary for the triumph of evil is that good men do nothing.
With so many clients deploying on Windows, who needs to waste time putting in a back door?
Its built right into the OS.
Cheers,
prat
I've written backdoors into web apps I've written, but usually because SOMEONE has to have absolute access to the data. It usually leads to some admin tools I've also written for the site, so that I can change data or whatever when needed. They aren't used for malicious reasons, and don't allow access to everything on the system. Although, hypothetically, if I were ever fired, it might be possible for me to get into those admin tools and issue the Apocolyse command that I've also written into the site, requiring the company to hired me back as a consultant at $125 an hour to fix things. Hypothetically. Not like that's going to happen. Really...
The program came in handy a few times. I finally deleted it about six months later.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
... i wrote that for debugging since MS Crap system for the PocketPC wouldn't allow me to debug running programs on it (even though it SAID it could do that! == Total BS!).
.biz .
It was a basic TCP service that spitted out variables on request. And yes it was removed from the final version.
Note; What i do with Sockets, Processes and Databases at home is none of your
I often, during the course of a project, dream up ways to open a hole onto an application. So far, I haven't ever implemented any back door.
Why, then?
I had more than one experience where a client decided they didn't need to pay anymore. They had their product, they had control over their servers, they had lawyers and I didn't. Man, I wished I had given myself a way to shut off my work.
But ultimately, as others have pointed out, I am caught up in meeting deadlines and making sure the application itself works flawlessly. It is rather hard to come up with a solid system if you are from the start imposing extra workarounds for your backdoor. It's the type of thing that has to be added later, if you want to be sure your code works right. And by that point, I'm usually exhausted and ready to move on.
I don't need to. The rest of the code for our software is so insecure, that any number of people can get unathorized access with only the least amount of know-how. :|
Speaking of which, anyone need a C++ *NIX hacker? I hate my job
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?
I used to work for a software company that did software for banks - the big international ones. Not only that, but it was the crucial transaction processing software, the software that moves money around the world.
:-)
What used to suprise me was that we would go to do installs at the banks sites with a binary we would take on a tape. Although the bigger banks would often check the source code, they wouldn't check the binaries we installed.
The company was responsible for one system for one major bank that transacted hundreds of billions of dollars a day. When I'm planning my fantasy bank robbery, getting modified binaries into those key transaction systems is my method
closet prgramming"....
Us gay programmers have been doing it for decades.
Writing malicious code into an appliction is not only unprofessional, it is also unethical. If you haven't already, I would seriously consider firing this guy.
There's a growing sense that even if The Future comes,
most of us won't be able to afford it.
-- Lemmy
One good reason that someone would write a backdoor is to insure that full payment will be made after a project has been completed. Imagine Screwing over a consultant on part of the payment, to find out that your site's been disbled!
That girl's standing right over there and you're letting out all our best secrets!
We use them where I work, and in the future I'll allways concider using them. But then again I do embedded stuff and one has to physically have the unit and jump through arcane hoops to open the backdoor. Also we sell the units for quite a bit more than the hardware costs so there is not much incentive for a customer to hack into it, ala the iOpener. BTW I'm hacking a telocity ADSL modem to run QS Linux has anyone got anywhere with that??
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
Member of the LP in CT and an Objectivist besides, and the root of this thread is correct: trust, respect, and loyalty cut both ways. The root held up his end of the deal, and his employer fucked him over. I don't blame him for being bitter. I've been in the same position.
Call it an "Administration area"
I make these: http://beatseqr.com
I heard that there's this program called Mozart's Ghost that has a little pi symbol put there by the notorious hacking group, the Praetorians. Anyway, if you click on it while holding down control-shift-back-back-forward-punch, it opens up a backdoor and your screen goes all crazy. I think it let's you hack the gibson or something.
"It's Dot Com!"
I used to work for a company that wrote billing software. Our billing app that we wrote had an easy way to get root on the billing box, via a simple exploit. Although it wasn't planned as that, it was discovered shortly after we shipped it, and was unpatched for years.
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.
Dear Slashdot,
Thank you for posting this story. I was disappointed last week when I submitted same under my other Alias T. Duct Tape Ridge.
As I stated earlier all of us monitor slasdot stories with great interest.
PS: Just because you are not paranoid does not mean you are not being followed.
Help fight continental drift.
Where Matthew Broderick uses his Apple II (or whatever it was) to break into the NORAD server called WOPR? And the backdoor password is the name of the guy's son who programmed the thing?
So much for security . . .
I don't like to use backdoors, I'm not "that kind of guy"... Not that there's anything wrong with that.
Cowboyneal is my backdoor.
Oh, I'm sorry, I thought this was a poll.
Sub7 for life!!! i will pwn you all -mobman
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 ;-)
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Well, I just finished reading through all the posts on this backdoor story. I have to say the troll community really let us down on this one. I mean, a story about backdoors, it should be open season for trolls. With a story like this I would expect to see no less than 50% -1 comments.
And sure, there are tons of -1 comments, but no originality. Oh, you have the obligatory goatse links, and plenty of Jim Morrison "I'm a back door man" posts. Overall, I have to say the posts on this story have been kind of a let-down, at least for me, personally.
PS- Imagine a beowulf cluster of these!
This is even stronger argument in favor of
Extreme Programming techniques, in particular,
pair programming - you simply cannot hide your
backdoors long enough while constantly switching
partners and roles.
My other Beowulf cluster is... er...
*sigh*
i see some moderator missed the joke. hint: read it backwards
"Knockin' at your Backdoor"
Words & music by Ritchie Blackmore, Roger Glover and Ian Gillan
Note: This song is about assplay. Cornholing. Dirt-roading. Rump raiding. Turd burgling. Taking a ride on the Hershey Highway. Installing Linux in your buddy's boxen. It really should be the official Slashdot anthem, except that the authors were thinking of heterosexual activities when they wrote it.
Sweet Lucy was a dancer
But none of us would chance her
Because she was a Samurai
She made electric shadows
Beyond our fingertips
And none of us could reach that high
She came on like a teaser
I had to touch and please her
Enjoy a little paradise
The log was in my pocket
When Lucy met the Rockett
And she never knew the reason why
I can't deny it
With that smile on her face
It's not the kill
It's the thrill of the chase
Feel it coming
It's knocking at the door
You know it's no good running
It's not against the law
The point of no return
And now you know the score
And now you're learning
What's knockin' at your back door
Sweet Nancy was so fancy
To get into her pantry
Had to be the aristocracy
The members that she toyed with
At her city club
Were something in diplomacy
So we put her on the hit list
Of a common cunning linguist
A master of many tongues
And now she eases gently
From her Austin to her Bentley
Suddenly she feels so young
Sure, I write in back doors all the time.
Sincerely,
Ron Jeremy
Ken Thompson, co-inventor of UNIX, was given an award by ACM in 1995. In his speech he reflected on the trust we put in developers and computers.
Imagine if the first C compiler did two wierd things.
1. If you compile code that matched a pattern indicating it was a UNIX login command, then insert a backdoor to get root.
2. If you compile code that matched a pattern indicating it was a compiler then insert code such that implements 1.
Write the first evil compiler that implements 1 and 2. Then write a nice compiler but compile it with the evil compiler. You look at the source code of the nice compiler and it looks totally legit, except the binary has the same functionality as the evil compiler.
Ship the evil binary and let Linux geeks recompile their OS source with it, complete with built in backdoor.
The moral of the story is that source can't be completely trusted because you never know what the compiler will do. You can look at the source of the compiler, but what about the compiler that was used to compile that?
It's a chicken and egg problem, what if the first C compiler was evil? The only way to make sure to check the security is to check the binary. But what if the hardware architecture couldn't be trusted either?
The moral of the story is that Ken Thompson owns your box unless you wrote your own compiler in binary on a piece of hardware you designed yourself.If you write an applications program, you should gain intimate knowledge of the application and the environment in which it will be executed. If you don't, your code will usually suck (but you won't even know it until the users come up the road to the castle waving pitchforks and torches).
By applying that knowledge, a good analyst can potentially abuse the system and gain access to whatever s/he wants or needs.
This assumes the co-operation of the system owners, but even if you are a shady type you could just pose as a janitor and do the deed.
It's a bit different for systems programmers; they aren't constrained by application hardware and stupid management policies to the same degree that apps programmers are. But even with system utilities, it's always possible to get full access with a quick jaunt into single-user mode. For example, in my building, you could just cut power to the building, saunter in to the computer room as everyone else floods out (conveniently opening the doors for you) and re-boot your chosen node on UPS power with a Linux BBC. Create a new root-group or wheel account, reboot and whistle as you walk back out. Knowledge of the operating environment - who is in the server room when, for example - will tell you who needs to get a touch of salmonella in their sandwich twenty minutes before the big event.
The crackers like to say "knowledge is power", but that's not really the crux of the biscuit - knowledge is potential, and how well you can use your knowledge determines the power that you exert. People who write backdoors are either ignorant or insufficiently imaginative.
Using a code-generation tool to generate all my code for internet applications I ran into a problem area like this. The code allocated memory in several areas and did not free it afterwards. I ran tests several times to see if it would allow a more knowledgable hacker to enter the system and take control; several tests were successful.
I alerted my supervisor, who assured me that it wasn't a problem and he took no action and insisted I did not "screw anything up" by messing with either the code or the code generation software.
Then I alerted the person who wrote the code-generation software about the security hole, who dismissed it as I wasn't as knowledgable as he was in programming, so I obviously was doing something wrong or cheated when I hacked into the system.
In the end, I left it there as an unexploited hole. The company may never find it, and since it is a rarely used custom application (only several hundred hits a year) on it's own small-power server, it's not much of a problem. But did leaving it there in the end count?
I was attached to a software package that didn't have a backdoor per se, so much as an undocumented account with a password of "a" that you could not take out of the database without doing major surgery. The software also (used to, anyways) put the undocumented account BACK into the users table and and restore the specific records to their "default state".
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...
Who did what now?
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.
I don't put backdoors into any programs.
Dear Backdoor,
I'm sorry I haven't written in so long, but you know how busy things get. Maybe it's time for us to move on. I've found this great credit card database that uses default passwords. What can I say, it has so much more to offer.
Yours truly...
Has had incredibly strict regulation on backdoors and "easter eggs".
Backdoors = Instant firing. Not permitted whatsoever.
Easter Eggs = Depends on the company, some companies I have worked for have let these go through, others fire on spot, and others actually have a process to "approve" the easter eggs before implementation.
Either way, I was too busy programming real code to even have time to worry about coding backdoors and easter eggs.
~ kjrose
In a web-based hardware-monitoring product (reports on the status of hardware, does not allow changes to anything), we've built in several known ways to circumvent system behavior (including authentication and authorization) via configuration file changes. These are used internally to facilitate testing or debugging, or in the field to help with customer support.
Some of these are in the customer documentation, and some only documented internally.
However, these are not traditional back doors as they require access to the server. To make the change the administrator must shut down the application, change a configuration file, and start it back up. So, the application is at worst as secure as the server it is on - as is the case with many applications.
So, no, I've never put in a "true" back door, nor has anyone on a group I've worked on (that I'm aware of). But, we've put in many ways to get around system behaviors, some of which have security implications.
Not representing or approved by my company or anybody else.
So if you'd been as bitter then as you are now, would you have built in backdoors so you could now sneak in and hold them hostage?
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 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
and the one to which "kt" refers is described here. Truly ingenious. Even looking at every part of the source yourself can't protect you in a case like that.
And I don't personally know anyone or heard of anyone in my "network" who has, we are professionals. Doing such a thing is beyond comtempt. Nothing less than a typical skiddie virus/trojan writer.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
A while back, I used to work for a web development agency. The owner was the biggest cunt on the face of the planet, employee turnover was about 150%/year with about a dozen employees. I went from a junior developer, to sole developer, to lead developer in a few months. The owner even stole from me when I left, not for any gain, just general pettiness. When other employees left to start their own business, the owner asked me to crack their systems (I refused).
I was miserable in that job, and the owner knew it, and only made things worse. I could have installed dozens of backdoors in each application I developed. I knew the servers weren't patched for years at a time because the owner refused to acknowledge he screwed up when renting servers, and refused to let me spend any time fixing them up (we were micromanaged on 15min intervals). I knew passwords to dozens of clients' applications/servers off by heart, including each and every "big" client. There was no policy of changing passwords after employees left.
When I left, I was very bitter. I could have took that business to its knees.
I didn't touch the servers. Why? I'm above dirty tricks like that. I may have been treated like shit, but while I was working there, I was in a position of trust (whether the owner liked it or not), so I conducted myself like any true professional would.
I have been pondering this problem for months now... I am creating an online microscope / informatics database that has it's own access control systems.
.ini file, in a way that even if someone edited the file, they would have to restart the service in order to use the new password.
The problem that I have is how do you make a system secure, and also ensure that there is a mechanism to create the first administrative account in a way that won't be considered a back door by the customer.
The approach I have created is to have them enter an 'emergency password' when the software is installed. They can later use this emergency password to create an administrative account for themselves... or import data into the database from a previous export on another system (an xml file.)
I store the MD5 hash emergency password in an
Does anyone have a favorite technique for this sort of secure system bootstrapping? Are there any books that have approaches that are considered acceptable to people who need _realy_ secure systems?
Thanks,
-Jim
Celebrate Excellence!
for one thing, i would really be embarrassed to hear that such a "feature" written into software i'd been developing had been comprimised.
...
nevermind the fact that, if found out, you lose any bit of trust you might have earned from your customer and/or employer.
just my $0.02
The wise follow a damned path, for to know is to be forsaken.
In my consulting life, I directed our teams to code in backdoors to almost every system we ever built *by default*. Sometimes they were lifesavers, sometimes they were done for 'defensive' purposes (you don't pay us then....).
Also, I would say that you should watchout for timebombs and logic bombs in code. I have two systems that I oversaw the development of under less than ideal client conditions that to this day have a capability to cripple the entire system down by passing the correct URL. Fortunately, I never was told by mgmt to utilize any of these 'features'
More common than you might imagine...
But I don't program as a career...
- 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.
Yo mama's so fat, all the restaurants in town have signs that say: "Maximum Occupancy: 240 Patrons OR Yo Mama"
Yo mama's so fat, when she ran away, they had to use all four sides of the milk carton.
Yo mama's so fat, instead of Levis 501 jeans, she wears Levi's 1002's.
Yo mama's so fat, when she gets in an elevator, it HAS to go down.
When she haul ass she gotta make two trips.
When she dances she makes the band skip.
When she was diagnosed with the flesh eating disease the doctor gave her 18 years to live.
She put mayonnaise on aspirin.
Her cereal bowl came with a lifeguard.
When she goes to the zoo the elephants throw her peanuts.
Yo mama's so fat, she was born with a silver shovel in her mouth.
Yo mama's so fat, she sell shade.
Yo mama's so fat, when she crosses the street, cars look out for her.
Yo mama's so fat, people jog around her for exercise.
Yo mama's so fat, I ran around her twice and got lost.
Yo mama's so fat, she gets runs in her jeans.
Yo mama's so fat, her blood type is Ragu.
Yo mama's so fat, when she goes to a restaurant, she don't get a menu, she get an estimate.
Yo mama's so fat, if she got her shoes shined, she'd have to take his word for it!
Yo mama's so fat, she has to put her belt on with a boomerang.
Yo mama's so fat, she can't even jump to a conclusion.
Yo mama's so fat, she broke her leg and gravy dripped out.
Yo mama's so fat, she went to the movies and sat next to everyone.
Yo mama's so fat, she's got smaller fat women orbiting around her.
This is all hearsay from stuff I remember
A couple years ago the MS managers told all their developers that if they placed any easter eggs or any other sort of non spec'd items in their code they would be more or less fired. This came from an agreement with the government that anything in Windows that was not spec'd to be there would be considered dangerous and harmful, and the government would not be able to use Windows at all in that case.
"Not knowing when the dawn will come, I open every door." - Emily Dickinson
For an interesting take on this, read Ken Thompson's lecture on Trusting Trust. :)
Don't blame me if you're paranoid afterwards
After seeing this link someone posted:
http://www.phenoelit.de/dpl/dpl.html
I decided to try a few out on our AS/400. I was really surprised when some of them worked. Now I'm in the delemma of whether to be nice and tell Ops, or keep it to myself for a little extra job security.
Wasn't it a backdoor that allowed Matthew Broderick to play Global Thermal Nuclear War?
;^)
Fortunately, they were able to track down the original coder and save the day.
MS embraced and extended Christianity to come up with the self-lobotomization tricks used on MCSE victims.
I dont personally write backdoors as such, however in certain circumstances I do write phone home software.
If a person is known to be pirating and the product phones home, my servers can send out a response (on a per ip basis) that will ask the client to send more data about its operating system environment, the environment variables in place, email addresses etc. Basically any information available to the program.
This is totally legit in my eyes and its always written into the eula.
There is no breaking in or liability to the user because its no "listen and login" thing but merely an effective way to control piracy.
Additionally, these such systems dont allow for the company to get a shell on the server or do anything truely evil short of calling the local anti-piracy group on that user.
Backdoors that are effectively listening servers are _always_ a bad idea. If you need access use standard proceedures and keep an account on the system for maintenance.
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.
Comment removed based on user account deletion
I write internal applications for a large corporation and often leave in a backdoor. Here is the simple reason: support! When an app here is migrated to production, I no longer have access to perform tests or make changes. Oddly enough, I'm still expected to support the product and make fixes. My clients don't care that there is an 'Enterprise Standard' for security. They just want the application fixed. So I fix it. The bosses know and give it a nod and wink. Quick fixes make them look good.
Would I do this on a product that would be exposed to the internet or go outside the company? No. But for internal coding in this company, it's a must.
Our big web applications contain backdoors until we are paid for our work.
Usually these backdoors consists of running scripts to delete the database and/or code.
We've got it all backed up on our end, so it's simply a form of having control until we are paid without needing to go the legal route.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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.
should be ssh. You certainly don't want to write your own buggy backdoor. That is just schtoopidttt.
If a back door is exploited and the company looses lots of money, etc... They simply go through their source integrity system and hold the coder partially responsible... Even if the programmer no longer works for the company...
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
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:
ôô
In development I've never placed hidden back doors from the client.
If a client doesn't pay, there are legal means of getting payment. However the smartest thing to do is credit checks prior to signing up with a client.
Additionally, don't deliver the final release, or pieces of code until you receive full payment.
Otherwise you are asking for trouble.
In the many web applications I've built, there have been no "backdoors". However I also develop a level of trust with a client, and respect that trust. They are willing to give me admin / root on their machines, meanwhile I respect that, and tell them when I'm doing things, and why.
If there's no legitimate way to upkeep your software, it's built wrong.
-Sean
my favorite backdoors are not those that are obvious, but those that could be passed for a simple programming error... buffer overflow..etc
I add bits to get debugging info secretly and remotely, but I'd never be stupid enough to put a full backdoor in, lest someone discover it and use it for script-kiddieing.
Back windows are ok, backdoors aren't
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
but I always put it in the readme, and require a password.
www.cgisecurity.com
That's why they are contradictory.
The people that make official statements are not the developers.
The right hand dosen't always know what the left hand is doing.
Love the sig. Seems appropriate. The Eicar probably won't trip anything because of the space Slashdot puts in though.
Click here!
I think there's an Ayn Rand novel with exactly this event as a plot device.
It's not strictly comparable, though. A software application can be destroyed with no loss of materials or labor, and restored in a matter of minutes. A building can't.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
I've not yet had a situation where I thought adding backdoor was going to help.
I've removed several backdoors from code that was written by others, usually programmers that preceded me on a project. Obviously you don't want to remove a feature without making sure it's not being used first, so I always asked around or mention in a meeting that I'd like to remove a backdoor. There have been some entertaining "raised eyebrow" moments with operational staff and supervisors when they learn there is a backdoor into their system.
Why put backdoors in to ensure payment? just give the client the program deactivated, or running in limited mode where they can see all the features but not activate them, once they pay, you provide the hash to activate the program.... hmmm... seems as if Time Limited Demos/Shareware already do this.... On the other hand, if it is nessesary for a backdoor to be inserted into a program, make it impossible to find, and make it require multiple peices of information that must be present, also someone mentioned searching through the .exe file to find string values, simple enough would be to encrypt the string value in question before compling
I only put back doors into networked apps if asked to. I could care less about gaining access to some big machine, I've yet to work for anyone with cooler hardware than what's in my basement :)
My Other Computer Is A Data General Nova III.
We have a "backdoor" on our site, if you will. I quote it because it's only a backdoor in the sense that our customers don't login that way -- but it's well known within the company and has proper authentication on it. Does that disqualify it as a backdoor?
Our site was originally written by a contracting shop who put in a backdoor an neglected to tell us about it. Imagine how upset we were when we found it and found they were still using it despite the contract being over...
but that is because we are too lazy to properly add ourselves to have the same security if we would do it normally.
Mike http://thenextgenerationofradio.com
Good points. Related to this, it is also handy to put in easter eggs that will cause an application or website to spit out credits for the work -- might come in handy when interviewing and it doesn't hurt the client a bit.
Writing backdoors is an extremely stupid and dangerous thing to do.
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.
As a lawyer and developer, I'd say back doors etc. may work for payment insurance as a practical matter, but if it comes to a legal push and shove, one might best have the explicit right in one's contract and/or have a good layer on board-- one conversant with the idea of consequential damages.
What about all the great P2P software out there? There are alot of people downlaoding what they think is safe software, but how many back doors are in cracked software of the internet?
just a thought...
I would never write backdoors in my own programs, because I like to use my own programs and if there is a backdoor in it I woulnd't trust it.
It's like the novell tools for networking... many of novell's tools were just against their own network.
Novell had a backdoor in case the supervisor forgot the password. This was the worst possible thing thing they did... It was so easy getting control of the network a child could do it... and then install further backdoors and login/password registration programs.
The story about the F15's having a malfunction in case war breaks out is ridicolous... what do you think will happen when the enemy finds out how this backdoor works... then USA's F15's will be worthless...
Same thing goes ofcourse for newer plans...
My point is: 'any backdoor can be used against you' !
I have been pondering the implications of this type of thing for a while now. I am currently building in a backdoor AND telling the user about it. You can read more of the discussion here:
Remote Code Hosting
www.jmagar.com
-
Such an organisation is likely to have "change control" procedures to protect against the all-too-common production outages caused by careless upgrades/installations. These procedures may entail mandatory delays, sign-offs, handing over to sys admin staff, etc.
For a developer, these well-intentioned controls can feel like an obstacle preventing him from doing his job of providing working applications to his company's users. This is particularly likely if the rules are created and enforced by remote levels of management.
In such cases, there are a whole range of "features" which can be added, more or less openly, to an application to make it easier to correct problems and make adjustments without going through the painful ISO9000-style bureaucracy. The developers may not even think of them as "backdoors", but that's what they can amount to in practice.
To take a ridiculous example, someone I know was instructed to develop an application that parsed and interpreted a subset of Java at runtime for certain aspects of program logic. When he pointed out that it would be easier and more reliable to dynamically load real .class files, he was told that that was no good as the class files would be "executables" and therefore need a formal software change notice, but the slapped-together interpreter would be reading "config files" which could be changed more easily. The manager in charge of the project, of course, was several layers below the managers that dictated the procedures, and found it easier to design round the restrictions than to change them.
I was working for a company that went belly-up around 9/11. I was one of the few people kept on as a contractor, but I wasn't guaranteed that I would be paid. The product was going to be installed at a single (large) client. I put in a simple check to exit with an error message if the app was run past a date a few months in the future. I planned on eventually taking it out if all went well.
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.
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.
"How sustainable is the 'trust' between the developer and the client?"
Trust? Who needs trust when there are contracts?
I don't really care if the person coding my project puts in a backdoor if I can sue them into oblivion when it's discovered/used.
-R
- First, target a specific program and specific language construct and modify the compiler code for a corresponding malicious actions (trojans).
- Then, compile this tainted source to get a tainted binary and install it as the official compiler.
- Then, remove the trojan(s) from the original source code of the compiler and the trageted program and compile it with the Trojan binary. The Trojan-ridden compiler will insert trojans into clean source, with no traces in source anywhere.
I also heard unconfirmed reports that he actually did this, but somebody please tell me if you know.I am not aware enough about the code legacy of GNU/Linux, but is all the code in the GNU system from scratch? Does it legacy need to be checked for backdoors or are we to rely on a chain of trust?
was the biggest security installation ever. It was only as good as its gate guards.
Engineering is the art of compromise.
Sure, I have put in backdoors to my application. We need thm man. otherwise production supp does not let u have fun.
Nobody expects the Spanish inquisition....
I've never created a backdoor, but when I was about to be fired by an M$ consultant turned director (yeah, that was scary) simply because I didn't like M$, I wrote a script that if I simply visited a page, it would format the drive. Had it worked, this would actually have been effective since Mr. M$ didn't believe in backup/archives.
:)
I never got the opportunity to test it though
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.
Would You Like to Play a Game?
I've put in one easter egg, which was just a way to see a list of people who worked on the code. In my experience, coders don't have to put back doors in, the constraints business places on development for the most part make it impossible to write and install a completely bullet-proof system. By the time a large project goes live, there's usually still a handful of ways in that haven't been locked down. Just by paying attention to the overall system those kinds of holes will become apparent. Of course, developers are bound by ethics and morals to document and report known security holes, but we don't have the power to close all of them.
I don't really care if the person coding my project puts in a backdoor if I can sue them into oblivion when it's discovered/used.
If the damage the backdoor can do to you will cost you more than you could hope to recover from them by "suing them into oblivion," you'd be well served care a lot.
.sig: file not found
I have worked on a web project where there are 2 undocumented URL's. The first one will pull up the version info and debugging page and the second will pull up the same info and who the software is registered to.
This is as far as I would go.
The information there is enough to a. debug the software if it goes crazy. and b. sue someone for non-payment. (and c. put a funny comment in for an easter egg)
Worst case, if someone found it, they know who the software is registered to and some information about their browser.
The problem is that many of these apps are networked. If it was a standalone app, it's not a big deal to have a way to override normal processing. When you get into systems with remote access, that's when you are asking for problems.
I don't think I've ever written a web-app (and I've written, oh, I'd guess 50+ good-sized ones by now) that I didn't put a backdoor of some sort in at some point.
;-).
They were all basically debugging and/or admin backdoors of some sort, where either they made my life easier when I was programming ("let's see, for *my IP*, just set the login and password to *this one*, and now when I restart the app I can get right back to being logged in without waiting *again* for the database lookup, etc.") or when I was admining the running app ("OK, let me insert the god-cookie here in my cookies list, with the encrypted content that the app reads and then knows to grant me access to *this* URL that dumps out who is logged in and what they are doing right now").
Some of them I removed when we went live, some are still in there. Some were well known among my programming group, some I kept to myself so other people wouldn't mess with them (I was the sole or lead programmer on all these projects). I don't regret any of them, and don't consider any of them a security risk. None of them were ever there to grant me more access to anything -- I already had root on all these boxes!
I almost think it's common for these things to be in there, considering the tendency of programmers to be lazy
I think companies (and the courts) would be very foolish to persue legal actions against programmers who add backdoors unless they can show malicious intent.
Do you really want your programmers to have to work under the assumption that they could face criminal prosection for adding debugging hooks to their code? And what about back-doors that open up as the result of discovered security holes? Who's going to admit that their code has such a problem if they could get arrested for it?
This kind of environment will cause programmers to refrain from adding useful problem-solving tools to their code and it will end up leaving more security holes unchecked because programmers will be afraid to talk about them.
How secure are open source projects against those kind of attacks? In an commercial, close-sourced project everyone has a contract with his employer and is therefore less likely to introduce back doors. How are open source projects protected against back doors? code reviews before inclusion in the code base, maybe? obviously you cannot rely on some random outside dude stumbling over the backdoor while looking at the source code.
Long ago and far away, I developed network drivers for an evolutionary dead-end mutant of Unix. One of the network drivers would respond to an undocumented ioctl by elevating all the privs and quotas of the calling process. I would venture to guess that if any of these systems are still running, they are at government installations.
My office mate had put the code in to help test something, and he waited for a while to see whether anyone would notice. No one did. He told me, and no one ever noticed in the remaining years I spent at that company, through several releases of the O.S.
Knowing the exploit did make for some amusing moments.
How secure are open source projects against those kind of attacks? In an commercial, close-sourced project everyone has a contract with his employer and is therefore less likely to introduce back doors. How are open source projects protected against back doors? code reviews before inclusion in the code base, maybe? obviously you cannot rely on some random outside dude stumbling over the backdoor while looking at the source code!
That girl is listening right over there, and you're talking about BackDoors? You're giving away all our best secrets!!
Sig:
Navy nuke sub lifestyle?
IANAL (I always read that as 'I, anal', *shudder* - but I'm from the UK where scatalogical jokes are standard issue). Here at least, I think that your friend's actions would seen as blackmail.
If your friend had a contract with said employer, then he should obtain redress through the courts (blimey, now I do sound like a lawyer m'lud).
I would certainly never employ someone who acted with such lack of morals and aside from the potential criminal record, I'm sure it wouldn't take much for the 'dick' to destroy your friend's credibility. Remember Bernie Shiffman? Would you knowingly give him a job? - How about after you typed his name into google?
# init 5
Connection closed.
Oh...
I'm the only person at my office that you could call a "tech", so all of the apps I write have backdoors - otherwise nothing could ever get fixed. If there were more support people here, or if anyone cared about security, I'd need to tell someone. Unitl then, I'm the only one who knows. Backdoors just make my life easier.
the fact that there's so much discussion about whether it's ethic or not bothers me to no end. yall should be discussing about how this is prevented best!
I don't write backdoors and never will. The shear number of holes that I find that the company refuses to close due to time, apathy, or pointy haired boss temper tantrum day are ludicrious.
Back in the early 90's when I was looking for a job out of school I nearly applied for a job programming Poker Games for casinos.
But I didn't, because I was affraid of the temptation, the mighty temptation to make a back door. (when drawing a 2 of clubs, throw all the cards out but the 2 of clubs... jackpot!)
After which I imagined the difficulty I'd have breathing underwater.
PS: never have made a back door, what a pain. For those that say they do for "debugging", you've got me confused, what good is that? Why not just have an account? Are you working for free -- the customer doesn't KNOW you are debugging? why?
Just another feature to code and big security worry.
-pyrrho
I did, before I knew better.
"5... 4... 3.. 1... OFFBLAST!"
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
I write software commercially. I write backdoor/trojans into everything, and they are ON by default, but nobody would ever find them but me and my team of five. Even the bosses don't know they're in there and they can't afford to hire extra people just to search our mountains of code on a hunch. Screw the users - if they're gonna pirate our stuff, they deserve to CRASH AND BURN. HARD. And we know who they are and we can make it happen.
a fucking health care system that is connected to some outside network written by some company who wanted to put stuff like this in?
A real company has procedures for change management. That is, a programmer documents what changes he is implementing, and another programmer does code review and releases the changes.
At least this is how it should work if you work inside a company where your code might destroy production data if buggy.
Much of the internet crap is not tested, or rather it is tested by people who has never seen a line of code. People donøt understand that better development quality will save more on less debugging time.
Povl - Former programmer. Now inhouse security consultant.
Lets you break into computers when people steal your software.
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.
In hindsight I probably should've clarified that a bit more. How about: "Backdoors left in by developers seem to be on accident rather than intentional.
C - A language that combines the speed of assembly with the ease of use of assembly.
I was subcontracted to build a Delphi app for some other folks. The payment was going to be some pocket change up front and then a percent of sales.
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...
In the Portland, Ore area and like card games? Check out: http://groups.yahoo.com/group/portlandgames/
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
How secure are open source projects against those kind of attacks? In an commercial, close-sourced project everyone has a contract with his employer and is therefore less likely to introduce back doors. How are open source projects protected against back doors? code reviews before inclusion in the code base, maybe? obviously you cannot rely on some random outside dude stumbling over the backdoor while looking at the source code!!!
One of our customers is the U.S. military, who, surprisingly, doesn't like any backdoors or easter eggs in the software we deliver.
At my company, implementing a backdoor or an easter egg in shipping software is a terminable offense.
Just for reference:b ility"h ave to"
"prove"
"compromise"
"code"
"denia
"shortcomings"
"perfect"
"referrals"
"
Just for reference, there are debuggers for the English language. They're called "dictionaries".
Backdoors are a fact of life. Every major vendor I've worked with calls it a "support line", or some other method to get to the servers running their apps. Microsoft W2K SP3 and XP SP1 have a "backdoor" as part of your license agreement.
If you want something secure, put it in a filing cabinet, or write the code yourself (Of course making sure you put in an easy to remember backdoor).
STFU & GBTW
Maybe it's just because I work for a defense contractor, but putting deliberate (security) backdoors in programs has never even really crossed my mind. Even with unclassified systems, it'd probably mean the end of my career. Or at the very least, it'd cost me my job and my security clearance.
That's not to say I haven't put some undocumented features in place, just not ones that deliberately compromise security. They're simple debugging tools - an extra URI parameter that makes an ASP page report (in HTML comments) SQL statements executed and profiles execution times.
Maybe the mindset is different in the commercial world, but here it's a given that someone else will be responsible for your code someday, that there are many eyes watching for things that don't belong.
People get this cloak and dagger impression of security in the military... I don't think that fits at all. It's all about paperwork and documentation and following procedures and regulations. Yeah, I've got a security clearance, but I avoid having to mess with classified stuff whenever possible. In truth, most of it's pretty boring stuff, and it's a pain in the ass to deal with.
The bottom line is that all of us here take too much pride in the quality of our work to deliberately compromise it.
Why would they need a backdoor when you willingly give away the farm when you click OK during the EULA phase of install? MS backdoor = front door in broad daylight
Come and see the violence inherent in the system!
Interesting question... I have never and would never build a back-door into anything I code, unless it was approved and well-documented (some clients might want it).
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?
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
okay, so here is your scenario. a former employer screws up code and hires you to help them fix it. wouldn't they give you the access you need willingly? why would you need a back door? also, how excited are they going to be by the prospect that your repair work was facilitated by a security hole? this whole scenario is a crock of shit.
Embedded applications are the worst place ever to place backdoors. Need I point out the Alcatel DSL modem issues caused by default passwords and backdoors for Cable providers?
At least on a computer, upgrading the software or replacing it is easy. In a fix environment, it's very bad to have any kind of insecurity.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It probably does not qualify as a backdoor, but we make sure we have a fully privileged account on every system of our customers. This greatly facilitates support.
I sometimes put one in to execute SQL statements for debugging but it could certainly be nasty if used maliciously (drops, etc.)
...I guess this is redundant when the DB is MS SQLServer...
I'm not kidding. I work for a major software publisher (who will remain anonymous so that I can keep my job) who as part of our annual design process include a design specification for an easter egg in the product. Even QA spends time testing the easter egg.
No back doors, of course, but I'm seriously thinking about putting "phone homes" into some of the things I write.
Look, you write something, you give it to the client, you hear nothing. Is that because you've written a brilliant bug-free piece of code? Is it because each member of the client's staff has run it once and hated it and gone back to doing things the old way? Is it because nobody has run your code yet because their part of the system isn't ready?
It's usually the last reason, of course, but I'm seriously tempted to put in a "phone home" one of these days just to find out.
A good example is a web-based app I developed for our intranet. We were having trouble debugging customers problems with it (normally PEBCAK - and we'd get useless reports back from customers, and be unable to replicate the problem since we couldn't log in as them).
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.
Sloppy, Sloppy! Especially if you are working on a client/server or n-tier application.
Every Database has a 'users' table which is used to control who is loggin in. The applications I have designed also had a second 'users' table which contained application specific data about the user. One of the columns in this table is 'access level', which were usually integers 0-10. 0 was the lowest level and 10 was GODHOOD. Regular application administrators could be given a access value some where in between.
During the log on process, query the application users table to get the 'access level'. Code in the application is executed based upon this access level. Yes, this is more work but if you are going to do it...might as well do it right. This method has several advantages:
1. No user names/passwords are hard coded into the application.
2. Passwords can changed periodically.
3. The application can literally be totally different depending upon the access level.
4. The back door is removable. Simply change the access level for that user.
Any one have any better ideas???
SELECT * FROM User WHERE Clue > 0
0 rows returned
Good idea!
p.s. think 'ewoks'...
I admit it. I'm a backdoor man.
I have her leave the key under the... wait a minute! I'm not going to tell all of you! Not that most of you would do much of anything beyond fix her computer and take an hour to tell her what the letters on your t-shirt mean.
We now return you to the actual topic.
I do know that the vendors who sell production systems DO put backdoors into their software. You'll never hear it from them, but they are there. Places to look:
- hidden commands or parameters that are undocumented. Any vendor supplied shell commands or script interpreter is a likely place.
- A "license server" supplied by the vendor to limit the number of seats on your LAN. Often they have training codes for classes or test codes for field service, probably also a special key to disable the license server.
- Any vendor process listening on the network.
- Commands that take datafiles or config files as inputs or parameters often have either hidden parameters or special files that they honor. A good example are PostScript interpreters. Almost all of them have some fun stuff squirreled away in the dictionary, and some of it explains alot. You can read the PostScript VM's dictionary like a book if you can find the interactive mode (like ghostscript's default prompt of gs>) or by reading the startup files for PostScript code (though some entries are hardcoded in a binary or lib) or by writing an EPS file to dump the whole dictionary to text file for you to leaf through later.
For Intel and SPARC, you can download a decompiler that will turn an executable or lib into a disassembled text file. A little assembly and a lot of patience, and you can find all kinds of fun fact. The 'strings' command in UNIX also works, but it only returns what look like "strings" even if the string is AAAAA or some other junk. You can learn a lot of hidden config options from a binary with strings, which comes in handy if you take on a new job and your new co-workers have "lost" the system manual(s).
Democracy. Whiskey. Sexy. Pick any two.
What about those malicious carpenters who build homes with backdoors?
and make everyone else use the back door! People never see it coming.
Escape Pod Films: Sketch Comedy and Web Series
Some years ago I worked for a really big telecom firm shipping POTS telco equipment to almost all countries in the world. We had this really smart guy who was working with a command module (a module that receives the CLI command the operator would type to configure something). During system test, one of our testers saw something in the code which looked really weired. It was not really weired but the code in this particular piece of code did something which wasn't obvious. The tester tried to enter a commad which excercised that particular piece of statements. Nothing happend. After a while he discovered this code was dependant on a specific type of hardware configuration. After this was set up he tried again to fire off the command. The reply was:
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.
I recently designed a web application for a customer and it was build it ColdFusion. Now as it got closer and closer for them to pay me, it became apparent they were only going to pay me 7K instead of the 15K I was contracted for. So I encrypted the source code using a simple ColdFusion encryption program. Now the encryption is easily breakable, but they didn't know that. When they went to edit the code on their server it was entirely encrypted.
I told them if they wanted the source code they had to pay me...
Let just say I ended up getting paid pretty quickly...
In any web system I've written, I've given myself a login to get in and troubleshoot early problems the client might have. Once the system is stable, I tell the client that they are now the administrator, and they should remove my login and change the administrator password.
Every so often I log into those old systems, to check. Not one client has ever done what I told them.
I think most computer users just care whether a system works, and don't really care about security.
I had root access on a particular web server. Somebody decided that I should no longer have root, so the root password was changed. However, my account was not deleted.
/etc/passwd, replaced the root password with the old root password (no shadow file; it was an old system), and added a line to the script that would replace /etc/passwd with my copy. It worked, and I had root again. Naturally this caused some confusion, but it was fun.
;-)
What nobody realized, and I hadn't thought of until then, was that there was a particular script in my home directory that was run as root by a cron job every night - something to do with updating the web site, I don't remember what it was. I copied
While I was building a secure internal web site at my last job, I set it up so if you were in the admin group, it would let you run a script (I named it su.pl) that would take any username you specified and log you in as them. When I showed this to the other developers, there was some hesitation about whether this was a good idea or could get us into any trouble, but it soon became apparent that this was absolutely essential to development - how can we write and debug a tool that only a manager has access to, if we're not managers and therefore don't have access to it? It was a hell of a lot more secure than creating a traditional backdoor, since I had to log in as myself first and I didn't know anyone else's password.
A neat trick I heard suggested once: if you're concerned about getting fired and you want to get revenge if you do, put something like a log rotation script in your home directory. If your account gets deleted, chances are your home directory will be rm -r'd as well, and the script will no longer work. Without log rotation, the logs fill the disk and the server bites the dust - and it wasn't your fault at all.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
After April 16th of this year, the HIPAA standards will go into effect for health care orginanizations. It's a set of guidelines that outline billing, among other things. One of the big issues is patient privacy. Take a look around. It's pretty interesting. Networks are required to be locked down, or the HCO is subject to an XX,000 fine for each patient privacy violation. (I think it's 35K, but I'm not sure.)
Implications:
802.11b? Hohahahaha. Nice try. Not until there's a better implementation.
Backdoors? They're right out.
All of this is nice, in theory, and I'm sure that there will be HCO's that might try to cut corners, but this is an issue that is being pushed quite a bit with respect to the technical aspects of patient data storage and access. LET THE FINES BEGIN.
So far, 3 tech savvy docs have asked me to do a war-walk of their hospitals because they knew that they weren't going to pass muster come April, yet their administration (IT or otherwise) wasn't concerned. They simply wanted some proof that they could lay on the table, and I was one "of their techie friends." (yeah,yeah, perhaps a little risky) One was running their WiFi wide open (!!), and the other 2 were using WAP, but after an afternoon of sitting in a lobby, I got enough 'interesting' packets to yield the key. I hope it helped light a fire under someone who mattered.
Additional links:
Encryption / Internet Policy
More Internet stuff
-- I'd say your post was about 3 monkeys, 18 minutes.
I tried to write on her backdoor once, but she turned around and slapped the hell out of me.
Cheat modes are often put in to facilitate testing by the various testing teams (generally the developer's team and the publisher's team rather than the manufacturers' teams). So even if it is for example a cross-platform title and has various debug/release builds, the cheat needs to be in the release builds for the testers to play it thoroughly.
It is a bad idea to test one version and then release another to the public.
Other "cheat codes" are used for publicity, notable "Banjo Kazooie" N64 but by their public nature these should really be thought of as part of the gameplay or difficulty setting or marketing mix rather than being back doors. The waters have been blurred between these two uses however.
...that's WEP, not WAP...
Hello? Medical records? Yes, I'd like to get a copy of my file. What? On my cell phone? Great!
anyway...
-- I'd say your post was about 3 monkeys, 18 minutes.
And how does that differ from normal prejudice?
Managment using a flamethrower?
That I'd like to see!
writing a backdoor? Just make sure it runs on MS products. The front door is always open.
Luckily, they didn't need anything as complex as a coded back door. We were also hosting their applications internally. I was instructed to go into the data center, hold my finger over their server's power buttons, and management told them to pay by 4pm, or their boxes would be powered off.
Needless to say, we got paid.
Unfortunately, the end result was they build their own data center, moved everything into their own environment, and cut all ties with us. A short while after I left the company, they went under. And this was before the dot-com bubble burst. (yeah, they didn't know how to manage an internet company).
Code review and testing is mandatory for software involved in any sort of safety operation.
Any software usage that doesn't mandate code review and testing is leaving itself wide open to not only malicious coding but egregiously negligent code and to the errors that result from failure to communicate requirements clearly or at all.
If you don't want to spend money to ensure the code is any good, you have no business complaining that it's bad.
...but my code is shit anyway
I do need back doors on ocassion but I try to put them inside an if statement so they only work on my dev machine and only on a certain day (so I don't forget to take them out and end up with a security hole).
Coding Blog
a winxp backdoor is like inserting a win2k system cdrom and have full access without entering any passwords :D
Putting a backdoor into code is completely unethical.
If I ever contracted someone to write software for me, I would put a clause in the contract stating that the developer agrees to pay me $1,000,000 if it is discovered that he put a backdoor in the code. It's utterly wrong.
Point 2 is totally invalid. With physical access, rooting most systems is trivial, and the rest are just slightly harder. Worst case, you pull the disk and put it in a system you have root on as a second disk. What if the miscreant disabled your backdoor before leaving too?
Maybe I wasn't clear enough - back doors are not in and of themselves an indication of bad ethics.
If it isn't bad ethics, then it is at least bad admin practice. At the very least it should be documented so that management knows and can have someone access it if needed. OTOH, there are ways to set up alternate access that I would not characterize as a backdoor. I've had hundreds of machines at a site that all could be accessed without password via an ssh login (with host authentication, of course) from a specific set of machines. In one environment, machines with this capability where refered to as "super-root" machines.
We all witnessed Admiral Kirk leveraging the ultimate backdoor in Wrath of Kahn!
If it's a good enough programming practice for the United Federation of Planets, it's good enough for me.
My house has a back door. Even if I'm the only one to use it, it's still a back door. It's still there and it can be used by others if they find it unlocked.
RMN
~~~
You can't ALWAYS read the code to find a back door. If you don't believe this, read Ken Thompson's Turing Award Lecture: Reflections on Trusting Trust at http://www.acm.org/classics/sep95/ It is also in Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763.
Companies routinely watch employees using network administration tools (ie. backdoors). Placing an icon in the tooltray doesn't negate the definition of a backdoor. It's only natural that someone does it to them.
And the world continues to go 'round...
The real question is: If an employee tests the ethics of their management by tempting them and the management oversteps the line what recourse does the employee have? At what point is management criminally stalking the employee?
+++ATHZ 99:5:80
And everyone knows Macs are the fastest computers on Earth. My iBook can crack all passwords on Earth in real-time!!
if ( strlen( pwd ) == 6 ) {
if ( ( pwd[ 0 ] == 'I' ) &&
code omitted because of damn lameness filter...
( pwd[ 4 ] == 'O' ) &&
( pwd[ 5 ] == 'D' ) )
{
return( TRUE );
}
}
You can muck with the order or do things like stuff the character constants into static int variables to really hide them, and if you really want to make it hard to figure out, do the password comparison code in assembler.
I'd bet nobody without knowledge of the code would ever figure that one out - as long as you use something hard to figure out like "Eat thE 39tH *Ugly* CHIPMunk!!!" as your password.
I've implemented a number of different projects. My experience in government development has been that backdoors are against the rules, so I did not implement them. Where I consult today, telecommunications, this is also the case - there are legal/contractual ramifications should a backdoor be uncovered.
In private industry, I've found that my customers expected me to be able to do anything required in the system even if they forgot or didn't know the administrative password to the system. Serving the customer was the primary reason for putting a backdoor into the system.
With the way that most systems are secured, my experience has been that hacking into root would be trivial in most production environments. Security patches can't be applied until tested and testing requires other business priorities be lowered, so they aren't installed in a timely fashion. If you are good, the patches are only 12 months behind.
Or at least change the default DBMS DBA account and password to something non-trivial.
I think it's: Strange Pandas Investigate Smelly Piles Of Panda Dung
-If
Run a pencil-and-paper RPG campaign with your far-off friends: Gametable!
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.
Goatse just poped up my mind...
speaking of open backdoors and such...
Hey! That's my sig you're smoking there!
Backdoors are a good move for independent developers, and not because of debugging purposes. More often than not, when someone commisions a programmer to do a project, they get about two or three weeks work out of him and then walk off with the finished code without paying. It's happened to quite a few people I know. They develop the apps, deploy them on their client's servers, and then never get paid. One guy had his erstwhile employer claim bankruptcy. He lost his car and his house. Then he started getting POST notifications from his software (debugging routine). Apparently the "bankrupt" company had taken what he wrote - line for line - and then sold the codebase to at least 15 other companies.
Besides the technical, there are very few resorts for the consultant that gets the shaft. Most of them are living from paycheck to paycheck these days. You think they can afford a lawyer?
Its fine for some of you to get self-righteous and say "backdoors are bad!" Get screwed a few times and you too will be investing heavily in remote administration routines.
Moral of the story: get the money up front.
Remember Jurassic Park?
There is a Playstation game with a back door that allows any copied CD to be put in and played.
The back door also works on the PS2 (in PS1 emulation mode) when running the same game. Could this be the first example of a multiplatform back door?
Some years ago when I was working for a Big Company (hence the AC post) I was the most computer-literate person in my department.
/var/mail/phb" but in the last second ethics/Fear-of-a-competent-sysadmin got the better of me.
It happened several times that someone gave me their password so I could help them do something from my computer, or log into theirs when they were at home, or somesuch. I never *asked* for a password but people often gave theirs to me.
Including my Pointy-Haired Boss.
Now, granted, the PHB was not root, but I still could have logged in and "been" him for meetings, e-mails, etc.
I almost gave in to the temptation once... PHB had disappeared (was being fired, but Upper-PHB wouldn't tell us what was up) and I telnetted and was all set for "more
I bet this has happened to a lot of people here...
and fire him fast.
I've never written any backdoors into any of the code I've written. It's entirely unethical. The fact that he took such an action is proof that he's not ethical, get rid of him.
Code or be coded.
I don't because of hte lack of time and the fear of being sued/losing my reputation after I forget to remove it.
The truth doesn't care what I think.
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:
http://homepages.nyu.edu/~teg205/final/Game.html
Hit the DEL key so you can see what you are typing. Then type "KRADRULES" in honor of the demo group, K-Rad Productions. Hit ENTER and walk around the map.
I still can't believe none of my project members ever noticed this in the code.
Yes and no--yes, I like the idea of having something disable even without my manipulation, but no, there are more tricks that clients like to use, specifically, other developers.
A fun little thing they like to do is to hire other developers to come in and mess with things in your code, like turn off expiration mechanisms. They pay another developer to find it, and turn it off. This way, the only thing they've paid for is the time of the second developer.
I guess I should qualify my use of backdoors--backdoors that only you, as a developer, know exist. If the client has no idea that you have backdoors, or what those backdoors are, they can't hire someone to get rid of them.
--My other sig is a ferrari.
Backdoors are coded for a reason. Obviously, the job didn't call for it. Call the FBI. You are not equipped to discern whether it was inconsequential. That backdoor served a purpose.
.com'd running as a pay-for-service business.
Nextime, structure your coding away from needing "trust" and "detrimental reliance".
Backstory: I had an entire project move off-shore through a backdoor via a coder. The project reappeared *whole* complete with the project application and name
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
for societies ills. Look, if the parents of that child can't teach him the difference of real life and fantasy play they are to blame. When that kid grows up and still can't distinguish the reality/fantasy he'll eventually get a real hard smack where he'll learn that he just can't hit the reset button. Blaming games is not the answer for everything. Blame the people who do stupid things.
--main reason I am against computerised voting. I'd bet a LOT there's all sortsa nifty "features" in the code that got "reviewed" and judged "ok".
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!
--dan
This posting is provided "AS IS" with no warranties, and confers no rights.
I once made a backdoor at my girlfriend's house...when she was out of town, I went through the back door and made out with her mom.
Other than that, I have only put a backdoor on the gibson.
Just check the Makefile for "LIBS = -lbackd00r"
I know what he would have to say if any of his employees were caught writing backdoors into commercial web applications.
All that we see or seem is but a dream within a dream.
Most "crackers" don't even look at the source code. Truly, how many people have even FOUND why sendmail has a buffer overflow. The rough idea was not released, but not the method.
Yet on the contrary, bugs or backdoors exist whether or not the app is open sourced. What good will it do to write a back door in a closed source environment? If you are intent on breaking the software, reverse engineering assembly language is an option.
void
However, if the backdoor or at least some mention of remote disablement, couched in legalese to diguise the implementation, is not part of the contract you may find yourself on the losing end of a lawsuit.
Unless the contract specifies that you can de-activate them for non-payment, it is illegal to do so. There is tons of case law on this topic and any competent attorney in the field will advise you the same.
This seems to have been (is?) pretty common in the network equimpment world. Quite a few vendors have 'God mode' passwords that allow access to hidden features of the devices.
I know some older Nortel/Bay equipment had God-Mode passwords that allowed you to log into the console, debug the box, read the raw hex, and even generate license keys for advanced features!
I've heard Cisco had/has the same type of stuff, and I bet other companies do too.
Thankfully most seem to be restricted to the console port only...
Now, here are my stipulations. Regaining access to said system's must only be able to be done locally. Ie, first you have to gain console access to the device running said binary. Note how this thwarts a geek remotely showing his friends how he's now able to change the balance on Heap Big Bank accounts. Secondly, the userid/password must only be available with information from both the client (consumer, person who paid for the product) and development company. Some of the client's information is information that is ONLY available to the client, not the development company. An example of this could be the IP address of the server. It could be a string that the admin or CTO chooses at installation. Something. It has to be unique and only the client can know it. A phrase or full sentence would work. Whatever it is it needs to be something that only the client knows (and should keep safe). Now combining things like serial number, activation code, client's unique string, and company's unique string together with an algorithm or two that only the company senior programmer and CTO knows should be adequate security for a backdoor. Since physical access to the machine is a must, this alone should be the crowning jewel in this security implementation. Now obviously the algorithms will also have to be present in the authentication code in the software. My solution for this would be that only the senior programmer in charge write this particular code (shouldn't be too hard) and the other programmers access it via a common API. Obviously they'll have to replicate a basic form of the code for their owd testing but it's neccessary to work.
It sounds like a lot of work. In truth it is. It relies on the clients to keep track of certain amounts of installation information and store it in a safe place. If the clients have a good DRP then this shouldn't be a problem. It also adds work to the development cycle but it shouldn't be much of a problem assuming the APIs are straightforward. Perhaps the senior programmer could release a version of the authentication agent to his programmers that doesn't have said backdoor algorithms. That's possible. Then he adds it at the end and they ship it off to Q&A.
Now let me say that I've seen something like this in action. I acquired a ethernet switch at work that hadn't been used in some time. It was a Cabletron switch. That particular line of switches do not have a dip switch solution to reset the passwords of NVRAM. I called Cabletron for help. After verifying who I was they took down the S/N and IIRC the MAC of the switch, pumped it through an algorithm, and then provided me with a password that would allow me to regain access to the device. IIRC it would only work when connected from the console. This is in no way any less insecure that Cisco's password recovery procedures. It requires physical access to said device and as well all know if that's happened, you're 0wned.
That's my $.02 on the matter.
backdoors? are you kidding? all the time. i even have a class prewritten that includes a debugger for variables, a debugger for key-trapping, a backdoor using a standard backdoor password, and a generic easter egg using the Desidoreplicator story from the Bastard Operator From Hell. i wrote a complete class for java and for VB, and have slimmer versions in C++ and PERL. yes it goes in every program i write, before anything else, a little tweak to fit the appropriate functions and we're off. as well, i've got a script that will insert an uber-administrator password into Access or. Filemaker databases. don't ever give me the slightest bit of administrative control. even if you delete the user account at the operating system level, i'll work my way around the damn thing.
.... but you gotta have a willing partner.
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!).
The number 1 problem of working in a cubicle - 23 power cords, 1 outlet...
Well, it is part of the contract that the software is not theirs until paid for in full. It is thereby our software, and we can disable it or add backdoors as we please. But thanks for the info, I will check out the case law on this and see if there's something that can help my company circumvent this problem...
--My other sig is a ferrari.
Mister Potato Head. MISTER POTATO HEAD! Back doors are not secrets!
I suppose none of the clients ever wondered why the mason had to come back with a ladder just after they paid the bill? chimneys rise high above the ground, and are built off staging. Getting a brick into the top of one is non-trivial, and not exactly subtle--particularly if it requires sweeping up broken glass once the brick is inserted.
Heh ..
Yes, I just called your backdoor a bug. A security bug. And the root cause of future headaches for all concerned execept the backdoor author, who will be long gone when the damn thing is compromised.
Background: I work for a school district, and a couple of years ago, the district webmaster asked me to check out something a teacher wanted to start using. It was a Java applet that would let teachers access grade reports for their kids just about any time, and even had a id/password feature for security.
I decided to investigate this thing to see how it worked, since it didn't need anything special on the web server. As it turned out, the basic premise was that you give it a uid/password, then it does some magic and jumps to another URL if it's correct. This (mostly) works since the directory index can't be viewed - you already have index.html populated.
This was just begging to be exploited, so I got a Java decompiler and turned it back into source code. From there, it was simple to see the algorithm they used to check the IDs and passwords. The actual data was embedded in the main web page alongside the call to the applet, and you could turn them back into a list of IDs and passwords. It was a simple rot-based cipher if I remember.
That's not the good part. The good part was looking at the source and finding something like this:
if ((pass == result) || (pass == 1066))
{ blah blah }
That's right - if you used 1066 as the password, you could get into ANY id, regardless of the actual password.
So, I took a few choice words from that page and fed them to Google, which presented plenty of other pages across the net. I did the decoding trick on the list of IDs, then gave it 1066 - *bing* I could see some middle school kid's math homework scores.
I believe this program was called Gradebusters or Making the Grade. Hopefully they don't use this any more.
In any event, we didn't approve it for teacher use.
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".
I18N == Intergalacticization
..say our developer friend here accidently forgets about the time-code. He could be called away on a family emergency or something, only to return to a rabid lawyer, a very irate company, and his reputation shot to hell.
That Jesus Christ guy is getting some terrible lag... it took him 3 days to respawn! -NJ CoolBreeze
Actually, a peer review *should* be conducted at some poi.r, whether closed source or not.
-- @rjamestaylor on Ello
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.
nuff said
It's that simple. The client has to trust the developer, and if that developer gets caught doing something malicious, it goes into 'big news' and that coder just lost his career.
/. and I mean, "IMAGINE A BEOWOLF CLUSTER OF THESE," ok enough :)
Just my $.02
P.S. I can't resist blabbing here how this problem might vaporize if everyone wrote 100% GPL code and had that code analysed by many eyes... after all this is
Sigs pose an operational security risk and help the baddies aggregate data. I guess commenting does too, oops.
I loved that game!
//e emulator and see if I still have the binaries, so I can toss it in the collection with Autoduel, Captain Goodnight and Miner 2049er.
Hmm...might even have to break out my apple
[yeah, yeah, I'm off topic...that's why I didn't use my karma bonus... hey, just be thankful I didn't mention Oregon Trail... hmm..that reminds me... I need Choplifter, too.]
Build it, and they will come^Hplain.
anyone think I am just paranoid ? Want me to show you the links to it ?
I have mod points and I am not afraid to use them
I've never intentionally coded a backdoor, but I have "accidently" left an extremely non-obvious hole that can be exploited in certain non-obvious ways to create an administrative account in order to access the system. It's not something you'd figure out by looking at anything accessible to anybody in any way whatsoever, just a side effect of certain behaviors of the application.
It's saved my ass on a number of occassions, such as the time when the client deleted the last admin account on the system and talking him through recreating it manually was a pain. I was able to get in and create a new one for him by exploiting the hole.
Of course, this is on an intranet application, not something available to the public. And unless you're a user of the system, there's no reason to break in anyway... It's simply not that interesting and has no exploitable information. It's critical data to the people who use it, but beyond that, nobody else would give a damn.
And the admin account is kind of limited anyway, as there's not a lot to configure. You can't delete the data, you can't access the system, all you can do is change the way it runs it's sequencing, so there's not a lot of point unless you're the one actually using the system.
Peer reviewing has several advantages in a commercial environment:
Ensure the code is correct, ie no obvious errors that will come and hit us during acceptance and therefore hit our bottom line
Ensure the code is efficient and well written, at the end of the day, when the project is completed, the client takes ownership of the code. It's its badly written, this could impact repeat buisness
Ensure the developers are not putting 'back doors' in. On a large development project, you should have a development environment and a seperate acceptance environment mirroring the production environment. Developers should never get anywhere near production testing code.
Peer reviews can help sell your company, if the client needs to be assured that you will develop quality code, then the peer reviewing concept will work in your favour.
/. posting.
Developers placing 'Easter Eggs' and 'Backdoors' in programs to me suggests poor management by their team leaders / project leaders / project managers. If legitimate back end access is required, by personnel authorised to perform it, then a mechanism that the client is aware of should be used such as a troubleshooter logon / password.
Just my 2 cents on my first
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
I don't like backdoors since they create all kinds of security leaks. If you properly test your system before going live you don't need a back door to debug.
BUT once I was asked by one of my bosses to put a backdoor in a system. The client was getting very hard assed about paying the money he owed the company for the development of the system. Inside sources warned us that the client is going to grab our software and cancel the contract.
What happened? We installed the system and sure enough the client told us a week later to go stuff ourselves. hehe a few clicks and what do you know the program suddenly developed a few 'bugs'. To this day the client never knew what hit him but it only took two days before we were back on the job with a bank balance the way it should be. The 8 hours of effort putting in a backdoor sure as hell beat the hundreds of hours in a court.
Carmack programmed a backdoor into Quake. Someone found it too. Heh. Some trick you could do and the Quake server would let you execute commands.
Can't remember the trick right offhand.
I wrote a client-server application for our company's use only and I created two hidden accounts in the client software to allow us (two programmers) to perform tests without asking the personnel to enter passwords hundreds of times. Since I am the sysadmin, there is not such a great risk (for now)
I've made it easy to disable security on development versions of systems I've written, just to spare myself the pain of logging in every time I bounce the web server to reload my .jsps, but I have zero interest in letting a real "back door" go into production. I'm not sure why. Fear of getting caught is somewhere on the list, but pride in putting out the best, most secure system I know how to make is a lot more important. In my current job I'm playing with real people's real money. Who cares if my company screws me over some day? I still don't want to make it easy to screw over some poor AOL-connected grandmother who pays her bill using my system.
I guess what trumps it all is that code with a back door is less elegant than code without, from a standpoint of efficiency. Lines coded versus purpose accomplished. So in my book, it's no back doors because of 1) Aesthetics, 2) Pride 3) Fear of getting caught.
I don't like it. What if they have to reinstall, well after the contract is over and they've paid? It will spontaneously break N days later, and they'll be (legitimately) quite pissed off.
For development, I didn't want to buy a lot of HASPs and so, so I removed the testing. However, as far as I can tell, I never gave anyone an executable w/o the protection.
Would you consider it a backdoor?
Come and see the Comun Yerge
Being ethical and following orders aren't necessarily the same thing.
Pathman, Free (as in GPL) 3D Pac Man
It think it was Bruce Schneider who once said that most security systems are like a 500 mile high fence that is only 2 meters wide that you can walk around.
:)
Point is, most modern encryption algorithms ARE pretty much extremely difficult to crack, even for the NSA but that there are so many oher buffer overflows and such crap that it does not matter really.
Here on good ol slashdot was a posting about how the FBI whacked some terrorists or something who were using encryption. They took the good ol' approach of breaking in and installing a keylogger on the guy's laptop to get the passphrase on his encryption key. Much easier than using a Ten-Trillion-Teraflop Bad boy of a computer to brute force the thing. More elegant too
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I don't do backdoors, but there are Eastereggs in all code I ever sold. More than once I have been asked to remove my name from the Splash/About screen, because it didn't look "professional" or some other bs reason. It makes me feel much safer if I have a way to prove I wrote some program.
who was responsible for modding this up as funny?
Don't do it.
Our current product has one quite official backdoor. It is designed to be used only by support people and because we have direct ISDN connection to all of our clients and their servers are not visible to the Internet, there is little risk at all.
:-)
The main purpose of the backdoor is to allow the support people to enter the system with full rights and without a licence. The client licences are floating so the support people does not use one of the licences and can log on even if there are no free licences left. A password however is always required, so that the authentication is guaranteed.
Internally there is another little hack, only the support people can see the full list of users, including the other support people. The normal users can not see and modify the accounts of the support.
It is so simple
A customer I was working for deployed our web application on a system we (the developers) had no access to at all. The application did not go through any form of testing before being deployed, so as expected, bugs were numerous.
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.
During development, sure. Get the underlying logic and interface working, then plug in the authentication. If the final product has a back door, that's like selling locks are, undisclosedly, set up with a master key, which you posess. /, replace or edit the file, reboot normally).
Of course, you want to permit the owner to uninstall the lock if he loses the key... or just wants to disable security, if he thinks that's safe. Same with software. Put the authentication in a discrete file, so the person posessing the system running it can bypass the application to set up newly-defined security, just like the unix password files.(boot to access the partition containing
"it's exactly like the car dealer coming and stealing your car after you bought it..." You must mean paid the down payment and up to 80% of the cost of the vehicle... Heck man, tow truck drivers carry a piece for people like you. That "latest version" thing is crap. However if I code a piece of software that you so decide to pay me after you've tested it and placed in production and come back to me and say "sorry, we can't afford it, thanks for you work" and use it later? Cripple that sh1t wit da swiftness.
When I was consulting for an ISP they received an email that identified a backdoor on their commercial ISP accounting software. This allowed anyone who knew about the backdoor to access user information including credit card data. The email included credit card information on about 50 of the ISP's subscribers just to prove the claim. We took steps to ensure that no one could gain access to that application from the 'Net but it was an eye-opener.
No one ever had to evacuate a city because the solar panels broke!
Right, right, right!
I'm sure that righteous "gotcha" feeling is nice when you tell the non-paying client that they must, after all, pay up. BUT it's much better to deliver a final product, and explain that it will only work until the end of the month, and that the non-time-limited version will be installed when full payment has been received. And then do exactly what you said. And be very friendly about it, and don't charge for the work involved in removing the expiration date.
Everything is so much easier if you're straightforward and forthcoming about it. Not naive... but honest. Now you've gotten the money you wanted, *and* you have one less enemy.
--
Everything should be made as simple as possible, but not simpler. Albert Einstein
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I used to work at a company that designed drinks vending machines -- those machines you get in offices that will vend you a chemical coffee at about 120degC.
The more sophisticated machines had a few microcontrollers on them, and the user interface was through push buttons on the front of the machine.
One of the engineering problems we faced was to deliver the machines at absolute minimum cost but with maximum functionality. So there was little room for extra buttons, switches or RS-232 interfaces on the inside of the machine where field service technicians would be able to get access.
Therefore, all diagnostic modes were accessed through a 'back-door', which was usually a certain sequence of button pushes on the front of the machine. This enabled the technicians to put the machine through its paces, turn on free vending etc.
Before you dismiss this as small-fry, let me remind you that these machines often contain cash (read: "company profit"), and also had the ability to use electronic token-based payment methods (I wouldn't be surprised if today's machines could do debit/credit card transactions). So, potentially, there was a huge risk with these 'back-doors'.
And, once development code had gone through testing and had been green-lit for use in production machines, the code was HARD-CODED into the microcontroller (this keeps the cost of the microcontrollers down). So if anyone was to discover the back-door, and could get drinks or money out of the machine, the cost of replacing all the hard-coded microcontrollers would be very high.
I once asked one of the other developers who worked on the customer interface electronics if, in addition to the field technician back-door, he had added any other back-doors, for example so that he could put the machine into free vend for only one drink, and thus get free drinks wherever he saw such a machine, and he replied that he had never thought about it.
I guess that means I've a devious mind. Or that he was a good liar.
"The noble art of losing face will one day save the human race"---Hans Blix
The superlative of "secure" is "most secure."
You are welcome.
Whoever modded this down (as "overrated", so he can't get caught in meta-moderation) is an asshole. Backdoors are unacceptable, and analogy in the message above is 100% correct. Sooner or later they are going to be found (just as security problems in the "front" door are found). Leaving a back door in a program you are writing for someone else is like keeping a copy of a house's keys after you install the lock. It's a crime, and jerks who do that kind of stuff should be arrested. An, while in jail, they would probably spend a considerable amount of time trying to protect their own "back door".
Ahem: http://slashdot.org/article.pl?sid=00/09/29/023124 8&mode=thread
OK. Let's review the score here. So the post topic was embedding backdoors. The thread that was progressing was on destructive backdoors. A comment was made comparing this activity to destroying a building.
I then make a comment (the parent of this one) about how this scenario has in fact been examined in one of Ayn Rand's books. I do this because it might be interesting to some folks to examine how Rand approached the ethics of the situation. Then I also mention some differences in the situation.
And some crack smoking moderator comes and labels this offtopic?!!? Bah.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.