As the “IT guy” guy at a small company, J.F.L. is tasked with all sorts of miscellaneous projects, from hacking together simple programs to setting up workstations for new hires. His latest assignment involved installing some rather expensive (as in, six-figure expensive) safety training software that would allow the company to keep track of which employees needed to complete which safety training modules.

One of the big selling points of the training software was its modular client-server design. The “server component” housed all of the videos, graphics, and course material, along with a database for employee accounts and testing certificates. The “client component” was a fairly basic application that connected to the server and allowed the end user to perform a variety of actions based on their security level. In theory, it seemed like a nice and clean design. In practice… not so much.

The first hurdle that J.F.L. ran into was the client program's requirements: Windows 95/98 or Windows NT/2000 only. This presented a bit of an issue, as one of the major reasons the company purchased the software was so that it’d work under Windows XP. Fortunately, after a quick call to tech support and a few hacks to the install script, J.F.L. was able to get the client software to install.

The second issue was the maximum resolution supported by the software: 640 x 480. Everyone in the office used 19” monitors with 1024 x 768 or higher resolutions. Since tech support’s recommendation of “change the resolution before running the program” wasn’t so feasible (Windows XP doesn’t allow users to select 640 x 480), that meant J.F.L. needed to another hack to get it working. Users would just have to deal with a small, 640 x 480 window in the center of their monitor.

J.F.L.’s main issue, however, with the new training software was its database. It was an Access database sitting on a file share. While that, in and of itself, is not terrible, the program installation required that all users of the software had read/write access to the share and had full access to the Access database. This seemed a bit insecure, so J.F.L. dialed up tech support again. They confirmed it: the program utilizes a single, non-password-protected Access database and writes temporary files to the share drive. There was simply no way around requiring full access.

Out of curiosity, J.F.L. opened up the Access database file and opened up the “Users” table. It had a column that stored everyone’s password in plaintext. And if logging on as another user was too much of a hassle, one could simply make himself an administrator with a quick change to the “AdminLevel” column. This presented a bit of a problem, since it would be incredibly easy for nefarious employees to skip past all of the required training modules.

J.F.L. rang up tech support one last time and asked if there was any way around this gaping security hole. “Well,” the tech support guy replied, “it’s really only a problem if they have Access installed.”

After J.F.L. told him that all employees have Access installed. “Hmmm,” the support guy paused, “I guess we never considered that. I will definitely bring it up with the developers!”

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!