This article details an experience I had while using the software MyMathLab, and overviews software security best practices. There is no information in this article that would allow students to alter their grades or cheat in any way, but details minor exploits in the software and security infrastructure related to “locking down” a workstation. This post was written for educational purposes relating to software development and security.
In keeping with security best practices, the software vulnerabilities were immediately show to both a math faculty member and a campus IT employee sometime before being published in this article.
MyMathLab is a software product, owned by Pearson (one of the largest textbook publishers in the US), including:
During the first-day-of-class-reading-of-the-syllabus my professor came to this line: “Do not use the computers in the classroom or math lab to use email, or use any other non-math website.” “Actually,” he said, “I’m pretty sure that the computer department locked down all of the computers, so why don’t you try, if you can actually get anywhere I’ll be pretty surprised, but come and show me.”
During my first glance around the software, I gathered some basic information:
MyMathLab is a web-application that allows students to
read from an e-text (a pdf)
watch video examples (in quicktime)
do homework in a flash application
watch math presentations (powerpoint)
MyMathLab runs in a stripped down version of Internet Explorer.
The entire computer seems to be under the control of some type of user-access control system. Attempts to click on the start-bar or the windows time are met with an “Unauthorized Function!” dialog box. I seem to be completely sand-boxed in.
There is no physical tower, or box powering my monitor, keyboard, or mouse. I seem to be using a terminal that connects to a MyMathLab server somewhere else on campus.
Thinking back to my experience at a highly micro-managed yet highly incompetent call-center, I remembered that my first, and probably easiest route to escape would be to find a dialog box that I could hijack and turn into a make-shift explorer window. From there I could navigate to anywhere I had permissions.
Failure 1: The weakest point in any system is the reliance on any third-party controls or software to perform a critical function.
Administrators will perform their due-diligence in locking-down any user access that they have created, but often fail to check, or even understand third-party systems that they give rights to — assuming that the third-party system will always behave.
This route of attack was remarkably simple, yet yielded a remarkable amount of access.
Step 1: find a dialog box
While the quicktime tutorials and the pdf e-text both opened in a custom reader, or at-least a custom shell of a known reader, the slides opened up right in a fully-featured Powerpoint session. I was a little surprised! I first went for the “open” button, which led to a “Unauthorized Function!” message. Good Job, guys. Open Recent and Save As were both dead-ends too.
“Let’s get creative,” I thought, and created a new document. That worked! I noticed that more of the ribbon appeared — I must have been looking at a read-only version of the math slides. Now I see more font control, as well as some shapes, as well as more buttons along the ribbon: Insert, Design, Animation, Slide Show, Review, View, and Format.
The Insert tabs looked like a gold mine: insert videos, images, objects(ole I’m assuming), etc. Inserting an image finally led to my dialog box!
Step 2: Explore Access.
I held back my hopes as the Image dialog box opened for me. A couple things could still go wrong at this point: I might only have access to my sessions Documents and Settings Folder or the file-type could be restricted to images only. I held my breath and click on My Computer on the left of the dialog box…
Oh. My. Word.
To test out my permissions, I right-clicked, created a new text file, and then proceeded to delete that file. Success.
Failure 2: Giving the user write permissions to system critical files.
Now for a look around: C:/ had all the normal stuff: program files, windows, documents and settings.
The most I dared to do was to open one the the DLL files in program files/mymathlab with notepad and make a small change in a comment section, save it, and then change it back after checking to see if it worked. It did. I also had access to the host-file entries that prohibited any access servers other than mymathlab. Probably the most damning however, was my ability to open the command prompt, which allows nearly unrestricted access to the inner workings of the local network, as well as the local workstation.
Failure 3: The workstation user account had access to the command prompt.
After class, however, my inner white-hat prevailed, and I ended up telling my professor what I had found, who then nearly sprinted up to the CS support lab and dragged a tech down for me to walk through my simple exploit. And seeing as I gave CS support adequate warning about the exploit, I now have no qualms about sharing my story, because I’m sure its fixed by now!
The moral of my story? Don’t be a bad programmer, don’t rely on third-party software/controls for essential functions, and most of all: don’t try and lock-down students, it just makes them curious.