13
saucyatom
26d

I just found a vulnerability in my companies software.
Anyone who can edit a specific config file could implant some SQL there, which would later be executed by another (unknowing) user from within the software.

The software in question is B2B and has a server-client model, but with the client directly connecting to the database for most operations - but what you can do should be regulated by the software. With this cute little exploit I managed to drop a table from my test environment - or worse: I could manipulate data, so when you realize it it's too late to simply restore a DB backup because there might have been small changes for who knows how long. If someone was to use this maliciously the damages could be easily several million Euros for some of our customers (think about a few hundred thousand orders per day being deleted/changed).

It could also potentially be used for data exfiltration by changing protection flags, though if we're talking industry espionage they would probably find other ways and exploit the OS or DB directly, given that this attack requires specific knowledge of the software. Also we don't promise to safely store your crabby patty recipe (or other super secret secrets).

The good thing is that an attack would only possible for someone with both write access to that file and insider knowledge (though that can be gained by user of the software fairly easily with some knowledge of SQL).

Well, so much for logging off early on Friday.

Comments
  • 3
    Is the configuration file on the client or your server? Or did I miss it?

    In the first case, if an attacker can write the config file, what else can he do? Read the database credentials? Replace the software as a whole? If so, it is only bad design, but not a critical issue (it should get fixed nonetheless).

    In the latter case it is still bad design, but the attacker could likely already write to the database.
  • 1
    (1/2)

    @sbiewald
    The client files should be on a network drive where ideally, normal users are only allowed to read. However some of our customers might not have the smartest admins, so it's difficult to be certain about that.

    To be fair, if one has write access to the whole project folder there are definitely more attack surfaces. The issue I see here that you only need write access to a config file (and I wasn't sure about how file access is / should be handled before discussing this with my manager).

    I actually spotted this while dealing the issue of another layer of security that could possibly be evaded (through extending said file in a non-malicious way). That one would be a comparatively small issue however (in terms of damage potential) and then this came up which is a thousand times worse, but yeah, I guess I was a bit overreacting earlier.
  • 1
    (2/2)

    I suppose going from "someone might be able to guess some protected data with a lot of trial & error" to "put this string here and fuck the whole db up" was a bit too much for me today.
  • 3
    I just got a late-evening reply from one of the seniors: Kinda what @sbiewald said. We have other issues and much easier attack vectors. ¯\_ (ツ) _/¯
  • 0
    !dev but similar boat... Discovered that pretty much any end user can inject SQL in a text field in my company's product that doesn't account for single quotes in any way...
Add Comment