Never ever trust client software for security

Never ever trust client software for security

There's a post making the rounds today about how you can use .htaccess edit access to create a web shell given just a bit of access to a web host. It reminded me of a time when someone tried to restrict access to some content without having been given .htaccess privileges. It did not end well.

The context is back at a public school district, where one progressive middle school teacher wanted to post grades online. We had no problem with this in principle, but wanted to be sure that privacy would be maintained. We were informed that it had "its own login system". Of course, that was totally fascinating, given that I (as sysadmin) had not given them the requisite .htaccess privileges to actually do HTTP auth stuff through our web server. I decided to check it out.

What I found was an index.html page with a bunch of weird parameters embedded in it, and then something very interesting: a Java applet. It would (eventually) start up and would ask for an ID and PIN. If you gave it a good combination, it would send you to another URL, which was just another file in that directory. Otherwise it would just deny you.

This system's security was more for looks than anything else, since it was all happening client-side. I figured it could be exploited, and then went and did that since it was a quiet day at the office anyway. Unzip was sufficient to open the JAR file, and "jad" decompiled it back to a reasonable source file. Everything else was just a matter of reading.

First, it grabs an ID and PIN from the user, encrypts the ID, and checks to see if it matches the "IDs" param set in the index page. If it matches, then it remembers which entry in that string matched, starting with 0.

Next, it encrypts their PIN and checks it against the PINs param. This encryption is slightly different since it uses the earlier ID offset to make it seem a bit harder to break. Of course, since we have the source code, it doesn't matter. The only other part left was their list of characters used for encoding: "qa0zw5sx9ed6crf2vt3gb8yhn1ujm4iko7lp".

While I did wind up using this to write my own decoder just for a good exercise, I found out that it wasn't even necessary. They had done half of the work for me.

   String encodedPin = encodeString(enteredPin, stuInd);
   if(encodedPin.equals(pins[stuInd]) || enteredPin.equals("1066"))
       proceed = true;
    else
       proceed = false;

Yep, that's a backdoor, and the code is 1066. Maybe they're history buffs. All you had to do is figure out an ID and then not even worry about a PIN. Given that kids probably could uncover student IDs of others, we deemed this to be relatively risky and advised against using it.

All of this happened over a decade ago. I just never wrote about it before. Since then, there's been a patch to their applet:

Version 8.5f
[...]
4. Removed the backdoor from the pinApplet on the Web posting.

Oh, okay. I'll certainly sleep better at night now.