Full Report
While looking at Cambium, the authors found a simple SQL injection vulnerability. As always, the authors were not using parameterized queries, leading to string concatenation for a SQL injection. However, the exploitation of this is what was interesting. There are a few limitations on the query. First, only integers can be retrieved from the rows. Using a UNION, we can query from other tables, but only integers. To get around this, the author converted each character into an integer. The second limitation was the rows being returned in random order, since this was an asynchronous call. To get the ordering, the author prepended the row index to the number by multiplying it by 1000 and the row index. The final limitation was the asynchronous call can timeout prior to returning the data. To make this more efficient, the author added more information to each request. In particular, they converted the character to a BIGINT, which can store 8 bytes of data. This resulted in the ability to store 7 times as much data as before. They tested this working on a local instance. When testing this on the cloud, they ran into an AWS Web Application Firewall (WAF) issue. According to the authors, WAFs either have a blacklist of words for recognizing SQL syntax or they try to parse SQL syntax from the request. The WAFs are trying to recognize the SQL syntax in the request. They tested hundreds of requests with many obscure features. In recent generations of SQL, there is support for JSON inside of it. While testing JSON, the author noticed that using JSON in the query made the WAF unable to parse the query. Neat! Does this work on other things? It turns out that other major vendors of firewalls were vulnerable to the same JSON trick as well! Considering WAF's need to be incredibly fast in their parsing, it makes sense they would not support every feature. Overall, good post for the vulnerability exploitation and WAF bypass.
Analysis Summary