Ruby on Rails
A common web framework for the Ruby Programming Language
Last updated
A common web framework for the Ruby Programming Language
Last updated
In Ruby, if you can execute any code a simple ` will allow you to execute system commands:
vs
In Ruby, is the standard module, and its functions do not need to be prefixed with Kernel., meaning Kernel.open() and open() are equivalent. A different function however is File.open(), which sounds like it should do the same thing.
One important difference however is that the open() function allows subprocesses to be created by prefixing with the | pipe symbol:
If you have control over the start of such a path, you can inject a | pipe symbol to execute commands. While you often also have Directory Traversal when starting a path with /, this attack does not require the / slash character and may get through a filter that tries to prevent it.
In ruby you can match a string to some regex in two simple ways:
These two ways are identical to each other, but not the same as many other programming languages. The uniqueness is that Regular Expressions are multi-line by default.
Similarly to PHP, Ruby on Rails allows you to put arrays in query parameters:
This will result in a params variable like this:
You can even use named array keys to create objects inside:
Finally, you can create nil values by not providing a value, which might break some things:
You can do a lot if you can find the Secret Key used for verifying sessions. Some common locations are:
config/environment.rb
config/initializers/secret_token.rb
config/secrets.yml
/proc/self/environ (if it's just given via an environment variable)
Ruby on Rails cookies use Marshal serialization to turn objects into strings, and then back into objects for deserialization.
For Ruby 3 you can use a piece of code like this to create a marshal payload executing any Ruby code:
For more recent versions, the following post describes a different deserialization chain:
More References
Take this vulnerable code example:
The vulnerability here however, is when we provide a sensitive attribute, which is easy as the path to the attribute can be deeper by separating them by underscores. If we want to find the reset_password_token for example, this is inside of the user:
/search?q=[user_reset_password_token_cont]=hacking. This query will return something if there is a user with "hacking" in their password reset token, but this can be abused by doing a character-by-character brute-force attack where we provide all possible starting characters and find which give a response back, indicating it was found:
Afterward, we know a token starts with 2, and we can simply try all other characters after it:
By continually doing this, eventually, we find for example q[user_reset_password_token]=2dd0571e439813f7 which shows the entire token is correct, and we have leaked it in only a few requests.
Leaking such hexadecimal token can look something like this:
In the example above, we try to find an object and property that when _eq is put on it, returns false because it is not found. Then the size is smaller and different from when the attribute is wrong, as then it is ignored returning all results in a static size.
This behavior depends, as in some cases a wrong guess will instead give no results, requiring you to change the fuzzing. A strategy for this would be to create a (mostly) always-true query like
?q[OBJ_PROP_cont]=_ asking for the property to contain at least one character (_ = wildcard).
There is no easy way to make start case-sensitive, but there are alternative predicates that are case-sensitive like eq (SQL =) or cont (SQL LIKE). Not all databases perform LIKE case-sensitively, some popular ones that do include PostgreSQL and Oracle DB.
While MySQL/MariaDB, SQLite, or Microsoft SQL do not. It is easy to test if this is the case by searching for a string with the wrong casing using the eq or cont predicates.
Commonly eq will work case-insensitively making it possible to guess all different combinations of casing for a token. If you found a token like a2b, you can try a2b, A2b, a2B, and A2B to find the correct one. Then, use this correct token to reset the password, or whatever else the sensitive data lets you do. Here is an implementation:
We can make use of this by specifying half of the possible continuations as an array in the query parameters, which will return results if the next character is in any of them, achieving Binary Search once again.
Some important things to note are firstly the fact that Ruby (and many other frameworks) accept arrays as query parameters by duplicating the names and appending [] like
?array[]=1&array[]=2 to create array=["1","2"]. We use this to generate the required strings. These strings need to be the known prefix so far, and half of the possible characters. If we know prefix="se" the guesses will be ["sea", "seb", "sec", ...].
Here is an example implementation:
In every situation, binary search will be faster than linear search, but the difference is largest when ALPHABET is largest. If this is N, the average time for both will be:
Linear Search: N/2 (N=50 -> 25 attempts)
Binary Search: log2(N) (N=50 -> 6 attempts)
Read in the RegEx chapter to learn how to exploit this. Below is an example:
See and for more input tricks like these.
First of all, you can of course sign your own data to create arbitrary objects that might bypass authentication or anything else. See as an example to serialize your own data.
The popular Ruby library allows developers to query a database in the form of objects. On version < 4.0.0 (Released: Feb 9, 2023), there is a big risk of mass assignment in query parameters that perform these filters. The client often provides a query where they can specify what attributes to filter for with conditions like cont (contains) or start (starts with). These can be pointed to sensitive data like password reset tokens by an attacker and exfiltrated character-by-character by the named filters.
Here the search page uses params[:q] from the client to query the Post class, which is indended to be searched for a title or content.
Then, a URL like /search?q[title_cont]=hacking will respond with all posts with a title containing "hacking". First is the path to the attribute: title, and then comes the Predictate: , separated by an _ underscore.
In this case, we found the sensitive user and reset_password_token attributes by reading the code, but in a more black-box scenario where you only notice the pattern of
?q[attr_predicate]= some guessing is required. Tools like can fuzz for these attributes by providing the FUZZ keyword in the correct part of a URL:
An important note, however, is the fact that the predicate is case-insensitive, meaning using just this technique we won't know the casing of a token. For a hexadecimal token, this is no problem, but for a Base64 token, it is important to get this correct.
If the targetted data is numeric, it is possible to use the lt (less than) or lteq (less than or equal) predicates to compare a range of values all at once. This algorithm is called and can drastically speed up your attack. Here is a simple implementation that leaks the number attribute from user:
A more advanced example is achieving Binary Search for string attributes. We require a way to test multiple values at once, to test a range (half of the possible values) at once. It turns out, the start_any predicate (similar to ) can do this for us! It requires an array and performs the regular start predicate with all the strings in that array, and if one is found, it is successful.
