CVE-2022-38867: Security issue: SQL injection in zhaojh329/rttys · Issue #117 · zhaojh329/rttys

Summary

SQL injection occurs on the server side of rtty: rttys.

Affected Version: v4.0.0<= rttys <= v4.0.2
Attacker could register a malformed account in server side, logged in and trigger the SQL injection.

I tried to contact to you using huntr platform, but it seems not work, so I post the security issue here.

Analysis

The sink point occurs on the /devs api route:

//api.go
authorized.GET("/devs", func(c *gin.Context) {
        type DeviceInfo struct {
            ID          string `json:"id"`
            Connected   uint32 `json:"connected"`
            Uptime      uint32 `json:"uptime"`
            Description string `json:"description"`
            Bound       bool   `json:"bound"`
            Online      bool   `json:"online"`
        }

        db, err := instanceDB(cfg.DB)
        if err != nil {
            log.Error().Msg(err.Error())
            c.Status(http.StatusInternalServerError)
            return
        }
        defer db.Close()

        sql := "SELECT id, description, username FROM device"

        if cfg.LocalAuth || !isLocalRequest(c) {
            username := getLoginUsername(c)
            if username == "" {
                c.Status(http.StatusUnauthorized)
                return
            }

            if !isAdminUsername(cfg, username) {
                sql += fmt.Sprintf(" WHERE username = '%s'", username)
            }
        }

At the end of the above code snippet, sql += fmt.Sprintf(" WHERE username = '%s’", username), ‘%s’ shows that username is delivered to SQL statement without sanitized. If we could control username variable，then SQL injection could be exploited. Coincidentally there is no sanitization of username when attacker register malformed account.

The source point occurs on username at /signup api route.

Meanwhile, if !isAdminUsername(cfg, username){ shows that only general username could trigger the SQL injection, that is good for attack.

Proof of Concept

1.Create a docker environment locally, using the docker command recommended.
sudo docker run -it -p 5912:5912 -p 5913:5913 zhaojh329/rttys:latest

2.Access the Web panel opened in http://ip:5913/, click Sign up to register new user. Because it is a docker demo, we have to register a admin account firstly.

3.After registered admin username, then attacker register a new malformed username xyz’ union select username,password,3 from account-- with any password like SecurityTest

4.Attacker logged in with username xyz’ union select username,password,3 from account–successfully, we could find that the password of admin and other users is showing, which is the result of exploit of SQL injection. As is showing below