What exactly does this do? Also can't you get kicked out of school for tampering with the system? I remember when I got into the schools command prompt from a student computer my principal went ape shit.

Ohhh so this LanSchool is added throughout any school board? What would be a normal highschooler do as a prank? Does not seem like you can do much that is not harmful.

Do you know if this still works on there latest 7.7 version?

I sent a message to Dana Doggett (the founder/president) of LanSchool to let them know there might be another exploit in there software. They have been taking security far more seriously then in the past when there was no encryption at all and hopefully they will have the issue patched soon, if it is not already.

Ohhh so this LanSchool is added throughout any school board? What would be a normal highschooler do as a prank? Does not seem like you can do much that is not harmful.

The lastest version that this worked on was, if I remember correctly, 7.5.x. My personal opinion about this matter is that LanSchool developers should really fix this problem from the root (e.g. server-based authentication or some sort of centralised control mechanism). If they attempt to fix this problem by simply changing or enhancing their encryption algorithm, an "exploit" like this will keep coming out (it only takes a few hours of playing around with debuggers to analyse and implement a cipher like this.)

I have been saying this since 2003.

They seems to want to keep the setup as simple as possible for schools and to have the client only require being installed. If it was me and I wanted to keep things working like that, i would probably look in to using public key cryptography to sign command packets. They could implemented a certificate system where they could have a master certificate which signs certificates for each school and the only set up would be adding the certificate to the teacher application and all lanschool clients would be the same and simply check that the cert is valid and the signature on the command/packet is valid.

However, once a person successfully obtains the private key (it is reasonably easy because usually a school has more than 50 computers, and every single computer would contain the private key of the question.), it is pretty much done (until you issue a re-deployment of the application files or OS image, which would result in a considerable amount of downtime; and as you may know, most central deployment systems are not perfect and usually few computers tend to fail in the process- requiring manual assistance).

Another major problem with the method is that it is very easy to impersonate the sender by dynamically capturing network packets (on the computer itself, or through non-switching hub if unicast or multicast, or even switching hub if broadcast). Once one obtains a packet sample, one can simply send the same packet over the network in the same manner (this requires no knowledge about encryption method or key). Also even if you design the protocol in such manner that each packet contains the sender IP, one can easily impersonate sender IP at IP protocol-level by physically hijacking direct router port (there would be a plenty of them exposed throughout the school building) or non-switching hub port (right next to your classroom computer, possibly?).

All these solutions will work to temporarily solve the problem. But the only way to completely and permanently secure the system is to implement a centralised system (and this should not take as much extra effort for site installation- literally one time, ten to twenty clicks should do it if implemented user-friendly).

p.s. Please add this discussion to the message that your are sending to LanSchool founder if you haven't already sent the message.

Not if the school then makes certs for each teacher with the school wide cert. Add in the ability to revoke certificates (which almost all modern certificate systems have) and you should be fine.

Also I would assume the private key would be in a network share only accessible via the teachers account. Not just stored on the hard drive of the local computer any student can get to or in the image with the client program.

The LanSchool client would only have access to a copy of the public master certificate which it uses to verify the certificate chain. It would not need to be updated with new public keys so long as the master certificate is not compromised. A central revocation list could be used if you are relay worried about a private key being stolen, but simply having reasonable expiration dates on the certificates would stop most issues.




There are a number of ways to stop replay attacks. A simple solution would be to add in a time stamp and nonce but there are more advanced methods.



I disagree. Public key cryptography should be a possible solution well allowing them to keep the multicast and distributed nature of lanschool. The only real issue is ensuring proper certificate management.

That's not to say that it is the best solution however, but it does keep things working the way they want.



I gave them a link to this topic.

All your explanations are indeed correct, except that the the idea of configuring a CA (with certificate share) and CRL violates the assumption you made earlier (keeping the setup process very "simple" as they are at the moment).

Also the method you suggested here seems more like a centralised way of authentication (since there is a CA that plays a major role in validating certificates.)

Either way, LanSchool definitely needs major improvement in its security featrure implementations.

The CA does not validate the certs, the client does. The LanSchool client has a copy of the master cert with the public key. The client could then check if any cert if valid by looking to see if it is singed with the master private key (using the master public key). Once the client knows a school cert is valid, it uses the public key in that cert to verify that signatures on command packets are valid and sent by some one with the school's private key (also would have to check timestamps, nonce and cert expiration date). The only thing a client would need to connect to is the revocation list periodically if you are using that feature.

However, in case of LanSchool, the server program (LanSchool Teacher) that signs all of its sending packets is exposed to public- must be distributed to all school computers (and so must be the private keys). As an alternative, even if you store the private key (would be pfx file for certificate) separately on a network location only accessible by certain user accounts (possibly SMB with AD), it is only a matter of time until someone eventually intercepts or obtains (using any means of method) the private key (as you see, by common design practice, transferring a private key over the network in a frequent manner is never a recommended method.) In my personal opinion, I would not consider this to be a complete or permanent solution. However, on the other hand, since who we are dealing with here is just a bunch of high students- not a group of professional hackers- I suppose this rather comes out to be a simpler and acceptable solution than I thought earlier.