I’ll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

  1. They were stored in a configuration file, in xml format.

  2. The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.

  3. This was then sent to the server as pure sql, no orm.

  4. Here’s my favorite part. You obviously don’t want anyone modifying the configuration file so they encrypted it. Now I know what you’re thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

  • mlg@lemmy.worldEnglish
    4·
    23 hours ago

    This one is funny because it 100% still exists somewhere, but I haven’t had the chance to verify it again.

    Okay so basically its a data recorder box (ex: brainbox) that connects to a bunch of industrial sensors and sends the data over the network with your preferred method.

    Builtin firmware gives you an HTTP webui to login and configure the device, with a user # and password.

    I think the user itself had a builtin default admin which was #0, which everyone uses since there wasn’t really much use for other users.

    Anyway, I was looking at the small JS code for the webui and noticed it had an MD5 hashing code that was very detailed with comments. It carefully laid out each operation, and explained each step to generate a hash, and then even why hashes should be used for passwords.

    Here’s the kicker: It was all client side JS, so the login page would take your password, hash it, and then send the hash over plaintext HTTP POST to the server, where it would be authenticated.

    Meaning you could just mitm the connection to grab the hash, and then login with the hash.

    I sat there for like 10 minutes looking at the request over and over again. Like someone was smart enough to think “hey let’s use password hashing to keep this secure” and then proceeded to use it in the compleltly wrong way. And not even part of like a challenge/handshake where the server gives you a token to hash with. Just straight up MD5(password).

    It was so funny because there were like a hundred of these on a network, so getting a valid hash was laughably easy.

    I never got to check if this was fixed in a newer firmware version.