LanSchool Cipher Algorithm

[Stephanos]

Mod Note: I moved this topic out of public view with the consent of the original poster to give LanSchool some time to fix there software. It was requested by LanSchool that I delete the topic but I left the decision to Stephanos and he agreed to hide the post for a few months. I plan on moving this back in to public view in about a month and a half to two months. ~Dan

Mod Note 2: The topic has been restored. ~Dan

Hello,

I reverse-engineered the LanSchool Student application last year to extract the packet cipher algorithm for some pranks and have finally decided to make it available to public.

Hope you enjoy writing your own "Haxchool" program based on this.


To read about the cipher algorithm, visit the following link:
http://stephanos.io/archives/200


p.s. If you need more clarification on how to implement the cipher, please do ask a question by replying to this post (that is here, not on the blog).

[Panphobia]

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.

[Dan]

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.

[Stephanos]

Panphobia @ Fri Dec 14, 2012 6:15 pm wrote:

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.

As you may (or may not) know, LanSchool added a new security feature to their applications (at some version around 7.x, don't exactly know which version it was) in order to prevent school kids from messing around with it (there were many student-made applications that allowed them to broadcast LanSchool control packets over the network and it was very simple to implement them- even for high schoolers). This article essentially gives you the key to nullifying that "security feature" (aka. packet encryption).

Regarding getting kicked out of school, it all depends on what kind of person your school principal is. Usually, as long as there is no major harm done to the system, it will result in a simple warning or few days of suspension. You might get kicked out if you abuse the keylogger functionality of LanSchool though.

[Panphobia]

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.

[Dan]

Panphobia @ 14th December 2012, 6:29 pm wrote:

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.

LanSchool contains many features that could be abused. For example you could monitor the screen, URLs accessed and keystrokes of any computer running it. In terms of pranks, you can also make all the screens in a computer lab go black, display a message, and other fun.

[Stephanos]

Dan @ Fri Dec 14, 2012 6:20 pm wrote:

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.

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.)

[Stephanos]

Panphobia @ Fri Dec 14, 2012 6:29 pm wrote:

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.

That's exactly why I did not distribute the actual program. I believe anyone who has enough knowledge to be able to read and implement this wouldn't be stupid enough to abuse it to do something that can get them into a real trouble.

(the best part of being able to control LanSchool is playing Trololo video on every single computer in the library.)

[Panphobia]

loool nice job , i would rather not waste my time trying to implement this, I have way to many summative assignments due in the next week

[Dan]

Stephanos @ 14th December 2012, 6:34 pm wrote:

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.

[Stephanos]

Dan @ Fri Dec 14, 2012 6:50 pm wrote:

Stephanos @ 14th December 2012, 6:34 pm wrote:

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.

Yes, that is definitely a possible answer to this problem as long as LanSchool program can prevent any other programs running on the system from accessing its resources (which, in this case, is secured to some degree). 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). Also it is important to note that, if application images are deployed at the time of system start-up, anyone would be able to obtain the image through the same process- most dynamic deployment systems do not have any strong security features).

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.

[Dan]

Stephanos @ 14th December 2012, 7:23 pm wrote:

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).

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.

Stephanos wrote:

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?).

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.

Stephanos wrote:

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).

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.

Stephanos wrote:

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

I gave them a link to this topic.

[Stephanos]

Dan @ Fri Dec 14, 2012 7:54 pm wrote:

Stephanos @ 14th December 2012, 7:23 pm wrote:

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).

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.

Stephanos wrote:

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?).

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.

Stephanos wrote:

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).

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.

Stephanos wrote:

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

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.


p.s. When I was writing my previous reply, I was assuming the concept of public key cryptography (in the way that it would not require any external source of authentication information other than the LanSchool program itself) rather than restricting the implementation to the usage of certificate mechanism.

[Dan]

Stephanos @ 14th December 2012, 8:04 pm wrote:

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).

I mean simple in terms of setup for the school. The certificate system would be set up by LanSchool, they would make the master cert and host the revocation list (if one is being used at all) and generate certs for each school (it would basically become there software key).

All of the clients would be identical and not need any set up beyond just installing it (which is what I mean by simple), the teacher application would just need a copy of the school's cert with private key (or if you want to isolate things more a copy of the teachers cert with private key, made by the school).

Stephanos wrote:

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.)

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.

Stephanos wrote:

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

Agreed.

[Stephanos]

[quote="Dan @ Fri Dec 14, 2012 8:19 pm"]

Stephanos @ 14th December 2012, 8:04 pm wrote:

Stephanos wrote:

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.)

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.

Glancing over the model you suggest here, essentially a packet is signed/encrypted with the school/teacher private key (master cert) at the server (LanSchool Teacher) when sent and verified/decrypted by the client (LanSchool Student) using the school/teacher public key (master cert). No person without the proper private key can sign/encrypt a packet in such way that it will be successfully verified/decrypted with the known public key- the basis of public key cryptography.

In almost all situations, this should work because the server program is not exposed to public. 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.