Security Vulnerability - SQL Integration

iain.whyte

Customer
Joined
Jan 24, 2023
Messages
1
Reaction score
3
Why when the blog says: All affected customers have already been informed directly by mail. We’d like to remind all readers that we have dedicated Security Alerts Forum. We urge all relevant parties to flag their concerns there and to follow the conversation for any further updates.

Except, the forum post is closed for replies. Why ?

What exactly is the nature of the vulnerability ? SQL Injection? Something else ? More detail is needed. "Just turn it off" is really disappointing. For how long?
 
SQL database integration is subject to vulnerabilities. We strongly advise you, as a precautionary measure, to follow the instructions found in our blog post without delay.

No further information can be shared currently. We will keep you up to date with further updates on this Security Alerts Forum.
 
Last edited:
Any update on this
 
  • Like
Reactions: TaylorStevens23
We will be posting a response later today or tomorrow early morning, if you have customers using that integration connected to the internet you will need to update your integration to make it secure. Examples and information will be posted today hopefully
 
  • Like
Reactions: Evolute IT
We will be posting a response later today or tomorrow early morning, if you have customers using that integration connected to the internet you will need to update your integration to make it secure. Examples and information will be posted today hopefully
Will the issue itself be fixed in the next update? I read the CVE. Or will it just be workarounds/modifications to the templates?
 
The issue is fixed in an update which will be posted tomorrow. However it should be noted that any database integration might need to be updated, that is to say if your queries are not protected against SQL injection in the first place. The easiest way is to install a web application firewall. The best way is to move to a secure REST API instead of direct database queries. it really all depends on your network configuration, the application and protection in place - its hard to say for all installs.

I apologize for any inconvenience caused.
 
Last edited:
Will this fix break a stored procedure? (i.e. EXECUTE sp_ContactLookupByNumber [Number]) My presumption is no, but I would like to have a bit of validation before I break my set up. I use a stored procedure to do look ups and inserts. The user account that my 3CX CRM integration uses is limited to only be able to access the stored procedures. Any input passed through is validated and/or trimmed within it. Never assume the user (3CX in this case) provided clean variables.

As with any security access, limiting what the accounts can do is must. I realize that giving SQL access to 3CX can still be a risk, but so can a web API that is not properly secured either.
 
  • Like
Reactions: N_G
Your query will continue working without changes, but now you have the option to invoke it as:
EXECUTE sp_ContactLookupByNumber @Number

and this way your database server will validate that what's inside this @Number parameter is not SQL injecting anything. For numbers you will not have security issues, as that's a value provided by 3CX and not entered by a malicious user, so it's safe to keep it like that.
 
Actually, [Number] will be automatically converted to @Number, so no change is required for this query, and you will be protected from SQL injection.
 
  • Like
Reactions: N_G and Evolute IT

Forum statistics

Threads
111,819
Messages
589,168
Members
164,642
Latest member
davids86