Buckle up kids, this one gets saucy.

At work, we have a stress test machine that trests tensile, puncture and breaking strength for different materials used (wood construction). It had a controller software update that was supposed to be installed. I was called into the office because the folks there were unable to install it, they told me the executable just crashed, and wanted me to take a look as I am the most tech-savvy person there.

I go to the computer and open up the firmware download folder. I see a couple folders, some random VBScript file, and Installation.txt. I open the TXT, and find the first round of bullshit.

"Do not run the installer executable directly as it will not work. Run install.vbs instead."

Now, excuse me for a moment, but what kind of dick-cheese-sniffing cockmonger has end users run VBScript files to install something in 2018?! Shame I didn't think of opening it up and examining it for myself to find out what that piece of boiled dogshit did.

I suspend my cringe and run it, and lo and behold, it installs. I open the program and am faced with entering a license key. I'm given the key by the folks at the office, but quickly conclude no ways of entering it work. I reboot the program and there is an autofilled key I didn't notice previously. Whatever, I think, and hit OK.

The program starts fine, and I try with the login they had previously used. Now it doesn't work for some reason. I try it several times to no avail. Then I check the network inspector and notice that when I hit login, no network activity happens in the program, so I conclude the check must be local against some database.

I browse to the program installation directory for clues. Then I see a folder called "Databases".

"This can't be this easy", I think to myself, expecting to find some kind of JSON or something inside that I can crawl for clues. I open the folder and find something much worse. Oh, so much worse.

I find <SOFTWARE NAME>.accdb in the folder. At this point cold sweat is already running down my back at the sheer thought of using Microsoft Access for any program, but curiosity takes over and I open it anyway.

I find the database for the entire program inside. I also notice at this point that I have read/write access to the database, another thing that sent my alarm bells ringing like St. Pauls cathedral. Then I notice a table called "tUser" in the left panel.

Fearing the worst, I click over and find... And you knew it was coming...

Usernames and passwords in plain text.

Not only that, they're all in the format "admin - admin", "user - user", "tester - tester".

I suspend my will to die, login to the program and re-add the account they used previously. I leave the office and inform the peeps that the program works as intended again.

I wish I was making this shit up, but I really am not. What is the fucking point of having a login system at all when your users can just open the database with a program that nowadays comes bundled with every Windows install and easily read the logins? It's not even like the data structure is confusing like minified JSON or something, it's literally a spreadsheet in a program that a trained monkey could read.

God bless them and Satan condemn the developers of this fuckawful program.

  • 9
    Custom software written for bespoke hardware is often amongst the worst still remaining in my experience.

    There's no competition - so nothing better ever gets created externally, so there's no motivation to make the official software any better.
  • 14
    The computer is secured via location based access, and the accounts are just so that careless users can't accidentally break things.

    Security is always a question of your threat model, and a controller machine for a test bench doesn't need access protection like online banking.
  • 5
    @Fast-Nop I was kind of wondering that myself, like.... Who the fuck wants to break into this anyway
  • 0
    Wow! That was unexpected! Not the slightest effort, nothing, nothing at all! 😵
  • 2
    @rant1ng well the OP I guess. Maybe he would have been happy if the system had been so secure that he would not have been able to help out. I bet his co-workers would have been happy, too.
  • 3
    @AlmondSauce Excellent point and I totally agree, I've experienced similar things with other machines that have controller software. I guess when you don't have to compete, you don't have to bother.
  • 4
    @Fast-Nop Good points, however, I do think that while this doesn't need to be super-secure or anything, it could at least have some effort put into it. Like not leaving full read/write access on, creating a proper installation executable and not a shitty VBS script, etc. That's the moral of the story here more than anything else.
  • 1
    @linuswillner My guess is the script either did registry things or was a crack of some kind.
Add Comment