Base64: a Self-Imposed Denial of Service

It is currently quite a frenetic time of the year at work. Students are in the midst of their final exams, and as always, people always find ways to conjure up some of the strangest problems.

Issue

I was out at dinner with my family on Wednesday night, and received a “Priority 1” ticket from a staff member in South Africa, stating that our “Learning Management System [Moodle] is down”… oh no…

After a lengthy call with the IT manager outside the restaurant, and an internal analysis from our developer, it turned out that the student had somehow embedded a 2MB image as Base64 code onto one of the questions he was answering, and due to the number of characters, it ultimately crashed the preview for anyone trying to view the image. I was originally quite concerned that this was some form of XSS attack, but upon analysis of the invigilation recording, it appeared to be a simple mishap.

For the time being, our developer jumped onto the database, took a backup of the database record, and cleared it for that question, so that the student could complete their assessment.

Findings

The following morning, we undertook a thorough investigation of the situation. Under normal circumstances, the Atto Editor would just upload an image and link to it, but interestingly enough, we identified that a certain version of the Adobe Acrobat Reader for Windows 7 (which is what the student was using) converted the image to Base64 when copying the image into Moodle.

One other major issue we identified, is that the text fields for quizzes on our LMS did not contain character limits.

After spending some time spamming text into a field with a Lorem Ipsum Generator (https://www.lipsum.com/), we were able to stuff in around 5MB worth of text, which naturally caused severe performance issues when trying to view the answer (over 10 seconds to load with 1GBPS down).

This, in my opinion, is extremely problematic, as some bad actor could potentially stuff a large number of characters in an answer, and cause huge instability on our database. Naturally, we patched this potential exploit opportunity up fairly quickly soon after by imposing character limits on all text fields.

Overall thoughts

This was a really fascinating issue to investigate. The title of this post is dramatic, but really this type of mishap uncovered a fairly valid susceptibility that was not considered.

Leave a comment

Your email address will not be published. Required fields are marked *