Dealing with (or implementing) insecure software in your organization...

Recently we/I've been asked to roll out a software program, which a teacher has selected and had licenses bought, that makes students practice there grammar and vocabulary. So far so good.

The problem is, this software's security is total utter crap:
Each student must register him/herself with a username and password... which are then stored in cleartext textfiles named with a sequential id (0.txt, 1.txt, 2.txt...) on a shared directory which everyone must have read... AND modify access to!

Normally, this utterly insecure design can be mitigated to some extent by setting the shared directory permissions so that new files are given CREATOR OWNER full control and other users no access so that only the user that created the userfile (X.txt) through execution of the program, can re-access and modify that file...

HOWEVER, in this case, this isn't even possible because, if you follow their design, in order to authenticate a user that logs in, the program scans the whole folder for the user files (X.txt), opens each one and compares if the username/password the user gave it matches the one in that file, if it doesn't goes on to the next (Y.txt) file and so on untiles it matches or runs out of user files in the directory! And to make things worst, if it can't open one of the files, it gives up trying to match with the others too!

So now I'm stuck with this crappy program and a list of cleartext files which store usernames and passwords as well as the user's list of accomplished activities which can be read AND modified by anyone who manages to find the hidden share. It's not that I really give a damn if this program user accounts get messed up, modified or cheated, we have severly warned the teacher and direction about this, what I really worry about is these kids (and even more the teachers who might use it) using the same username and password than their windows domain username/password (and God knows where else they use these same credentials!).

We have contacted the maker of that software (a BS home "basement" company of one) about these issues, to which there answers was: "the program is like that by design, there's nothing that can be done, you're (we) are over reacting, many schools use it and nothing's ever happend"... URGH!!!!!!!

Anyways, for now like I said, the teacher and direction have been severly warned (inluding us showing them the e-mail of the acknoledgment and lack of care from the developper) about these issues, but they still want to accept the risk and go through with using this crap.

So my question to you, fellow admins, is what more can be done? How would you deal with this situation?


Ammo

PS: I won't even mention the rest of the crap about having to install this product by hand on each machine...

First, are these kids who are going to have the skills to bypass the "security"?

Second, you need to make it clear that you will take no responsibility for any security issues arising from their implementation of this product. It's not your decision, but you can try to avoid the blame.

Third, management is obviously incompetent. Find a way to use this to your advantage.

If the manager choose to accept that in spite of your written position (i hope you did it written - for documentation - and your safety), you cant do anything else. It HIS attribution to do that. Just it. He took the risk.

My school had the same problem with the typing program we use (Micro Type Pro), except they didn't think anyone would be able to modify it. Heck, I don't think our IT people knew where the user information was stored. After a quick check, I found my file and cut it to floppy. I analyzed the file, figured out where the password was stored in it, and wrote a small C program to extract that segment of the file. The next day I codebooked all the characters and had a complete list. That night, I wrote a C program that would extract AND decrypt the password for an account, and list all the information in the user's file in human-readable form. I showed my computer teacher and said that I'd managed to do all of this in the space of three days and explained the potential risks involved and showed how someone could come in and not actually have to do any work. Nevertheless, we still use the same program.

I'd suggest perhaps going Open Source on this. I don't really know what's out there or how it compares, but it sounds like no one's going to want to pay to license new commercial software that doesn't have the same problems, so it might be your only choice. A quick search on sourceforge turned up one program that looked like what you described. http://sourceforge.net/projects/winvoctrainer/ . But, it's in alpha stage right now, so I doubt it'll do you any good.

The only other option (legal that is), would be to write some software yourself for free and just deploy that instead. Otherwise, you could try to reverse-engineer the mechanism that does the authentication, but that would be really ugly and probably take longer than just writing better software from scratch.

Quote:

---

We have contacted the maker of that software (a BS home "basement" company of one) about these issues, to which there answers was: "the program is like that by design, there's nothing that can be done, you're (we) are over reacting, many schools use it and nothing's ever happend"... URGH!!!!!!!

---

You have to hate people like this. That's the kind of thing that shouldn't be hard to change at all. It should be a separate part of the program entirely from the way the rest of it works. I can't imagine anyone actually DESIGNING a system that works as awful as you described. I wonder what language they made it in...

....and hence goes the saying that security is a balance between security and usability..... ;)

I'd suggest Doppel is about right - you are phecked.... Thus, place the blame elsewhere.

Audit the files regularly if you find teachers with username/password combo's that match domain credentials move them to a secure folder. When the (L)user tries to use their account it will fail, they will come to you and you will force them to change it and slap them....

Then you need to do what I did. Write a policy that get's signed off on by the top that states that all software/hardware purchases are to be passed through IT who has the final say on what is purchased and what isn't. You sell it to the top brass on the grounds that IT are best suited to know whether the software will run effectively on the systems and that will save the school money on "useless" purchases in the future. Then, when they buy without consultation in future you wave the paper in front of them and tell them it isn't going on your network and they should probably explain their waste of money to the Boss himself...... I only ever had to "wave the paper" once..... Since then I get consulted every time..... Funny huh? :)

Quote:

---

Originally posted here by D0pp139an93r
First, are these kids who are going to have the skills to bypass the "security"?

---

It's surprising how much skills some highschool kids can have... While I went there (did my highschool there too), a friend of mine wrote Land.c, you know, Land Attacks. He/we were 15 at that time... Of course I'd have to admit that guy is quite a genious and obviously not all kids can pull off something like this but still, this one ain't particularly hard to crack either...

Quote:

---

Originally posted here by FlamingRain
You have to hate people like this. That's the kind of thing that shouldn't be hard to change at all. It should be a separate part of the program entirely from the way the rest of it works. I can't imagine anyone actually DESIGNING a system that works as awful as you described. I wonder what language they made it in...

---

Oh but there's worst! The program, in order to check if it is able to write to a particular directory, writes a test file to every single directory in the path leading to it!!! Yes you read right! If it needs to write to C:/program files/foo/bar/, it'll write a file containing "test writing" to C:, C:/program files/, C:/program files/foo and c:/pogram files/foo/bar/ !!!! (Ok, should I scream or cry just about now?!) Oh and it also needs to be installed by hand on every computer because while installing it requires a unique computer number to be typed in... <despair>...

Quote:

---

Originally posted here by Tiger Shark


you are phecked.... Thus, place the blame elsewhere.

---

I think this will be my motto from now on...


Thanks for the feedback everyone...
even though it only pretty much confirms what I knew! ;)


Ammo

NEVER underestimate High School kids... I am one... I can tell you I would find something like that. I found plenty of security holes in our schools network... But our IT guy is of the arrogant type, so he would not listen to me. He just knew "so much more than me"... Yea right...

Piece of advice to you: when a kid tells you of security holes, take them seriously.

Your situation could make for a humerous post to bugtraq or full disclosure. hint hint

Quote:

---

when a kid tells you of security holes, take them seriously

---

If for no other reason than the fact that they are probably only the very tip of a very large iceberg you may consider to be long term, gainful employment....

Good point grunt....

First, I would just like to show my amusement that you are working with a program that should help children's grammar, but in your post you made some grammar mistakes. Mostly the use of the word there rather than their, I found it kind of funny. Not saying that I'm an English professor, far from it.

Here’s a possible solution that would depend on your programming skills and willingness to get this program working. Create a program that the students/teachers could log into. Your program then goes out to a secure folder and checks for their username and password. If it is found, then your program can move (copy) the file from the secure area into the normal program area and rename it 1.txt (or whatever). Then your program could activate the teaching program, enter the username and password (automatically), and send a carriage return (enter). Then, when the teaching program is finished, the user would log out on the program, and then log out from your program. At that time you could move back (or delete if you copied) the 1.txt file.

If the program gives you a choice where to install, then you could just put it in c:\, at least you could still stop access to c:\program files. You might also be able to find a special setting that could change the location of the .txt password files.

Quote:

---

Originally posted here by annihilator_god
First, I would just like to show my amusement that you are working with a program that should help children's grammar, but in your post you made some grammar mistakes. Mostly the use of the word there rather than their, I found it kind of funny. Not saying that I'm an English professor, far from it.

---

Ok, sure, I'll admit that two out of four "there/their" in my post were misspelled (a mistake many people do) and that it is somewhat ironic concidering the context, but then again, when your French is as good as my English, come back and talk to me about it! (to be taken lightly...) ;)

(In case it wasn't clear, my first language is French... )


About the rest of your post: it would be an intersting option, however my new motto has just changed to "you are phecked.... Thus, place the blame elsewhere." and this is just easier! ;)
Seriously though, if the stakes were higher and I had more free time I might have tried it but I don't think it's worth this much effort (as nobody seems to give a damn)...


Ammo

Ammo, Je te comprend mon cher! Je suis un québécois aussi!

Basically, these username/software systems suck by time. So don’t use it at all! Created the username/password yourself and make sure user cannot change it. Don’t waste time securing a software that cannot be sure. Just don’t use that security. With all users have same password, they will all be vulnerable. That it!

This thread is funny...


in other news...
High school kids hacking Mavis Beacon.