In my post about exploiting BigAnt server, when generating payload I'm entering 0x20 and 0x25 as bad character. How to search for a bad character in the application that will be exploited? Here's the way to do it. The application that will be used is still BigAnt server, but I think the method to find the bad character is the same in all aplication. This knowledge is essential because without entering the right bad character, our payload won't work properly as we wish.
Lets begin.. :D
- Use this fuzzer as the starting point.
- That fuzzer will overwrite the SEH buffer with the address of the VBAJET32.dll that have a POP POP RETN command inside. Lets try to execute it. But don't forget to place a breakpoint on the address of the commands at 0F9A196A.
- Execute it then see what happen in the SEH Chain.
- It contains the VBAJET32 address. Then lets generate the a payload using the default bad character 0x00 0x0a 0x0d.
- Insert it to our fuzzer.
- Place the breakpoint again then execute the fuzzer and see what happen in the SEH Chain.
- SEH pointed the wrong address, SEH supposed to point on the VBAJET32.dll address that we've placed. The problem is definitely because of the payload that we've generate. Usually this happen when a bad characters is exist on our payload. Lets search it.
- First step, we need to generate a dummy code contains all hex character start from 00 to FF. To do it we can use this perl script.
- This is the usage of the script.
# perl generatecodes.pl (badchar1),(badchar2),(badchar3),...(badcharn)
example
# perl generatecodes.pl 00,0a,0b,0c,0d
- Ok, generate it.
# perl generatecodes.pl 00,0a,0d
- Next, we must enter this code line by line. This will make us easier to find bad character. Also this will make the results more accurate although it waste a lot of time. But with regular training, this can be done less than 5 minutes.
- Ok, lets insert the first line to the fuzzer.
- Ok, place the breakpoint then execute the fuzzer. After that see what is the value inside the SEH Chain.
- Good, it contain the right value, VBAJET32. This means the first line doesn't contain a bad character.
- Insert the second line to the fuzzer.
- Again, place the breakpoint, execute, then see the SEH chain.
- SEH contain the wrong value. This means that in the second line there is one or more bad character inside. To make the searching results more accurate, divide the second line into two.
"\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
will be
"\x12\x13\x14\x15\x16\x17\x18\x19" and "\x1a\x1b\x1c\x1d\x1e\x1f\x20"
- Insert the first part to the fuzzer.
- Breakpoint, Execute, then see the SEH Chain.
- Ok, the first part doesn't contain any bad character. Lets continue to the second part. To make the search more precise. Lets divide the second part into two parts too.
"\x1a\x1b\x1c\x1d\x1e\x1f\x20"
will be
"\x1a\x1b\x1c\x1d\x1e\x1f" and "\x20"
- The division can be whatever you like. No specific criteria to do that. But myself I like to divide the words and number.
- Ok, lets insert the first section of the second part to the fuzzer.
- See what happen in the SEH when the fuzzer executed. (always, don't forget to place the breakpoint)
- It still contain the right value. This means the second section of the second parts is the bad character that is \x20.
- Lets generate the dummy code again with the addition of \x20 as a bad character.
- Insert it to the fuzzer.
- Ok, execute it, then see the SEH Chain
- Good, looks like we've found the bad characters from this application. But, to make sure that everythings going right we will compare the data in the buffer memory and the dummies sent. This process will find the bad character hidden inside the buffer memory of the application.
- To do this we must compare the data inside the buffer memory of the application after it is attacked by the fuzzer and the dummy data we've generated and inserted to the fuzzer before.
- Ok, place the breakpoint again then execute the fuzzer. OllyDbg will break the process when the application trying to access VBAJET32.dll. Then press Shift+F9. OllyDbg will bring us to the POP POP RETN command.
- Press F7 three times, this will bring us to the JMP SHORT command.
- Press F7 once again, this will bring us the location of 16 bytes NOP before the dummy code.
- As you can see above. We can see the beginning of the dummy code, "0102".
- Next is dumping the content of the buffer where the dummy code start.
- Click on the 0102 then right click > Follow in Dump > Selection
- Block all character start from 01 to FF then right click > Binary > Binary Copy
- After that paste to the text editor like gedit, kwrite, geany, anjuta, etc. Save with the name you like.txt.
- Then generate the dummy code again to a file
# perl generatecodes.pl 00,0a,0d,20 > dummy.txt
- Save this perl script to compare the value inside that two files.
- Ok, execute it.
# perl comparememory.pl binary.txt dummy.txt
- The value of \x25 is substituted with \x57. Lets see what happen in the buffer at that point.
- Value 25, 26 and 27 is missing. This means one of them is a bad character.
- To know what is the exact bad character we can exclude them one by one, generate the dummy code again using the data excluded as a bad character, sent to the application then compare again the dummy data sent and the data on the buffer memory.
- If there's no difference between them after comparation, that means the excluded character is the bad character.
The bad character is 25, you can try it yourself if you want.. :)
rest of the exploitation process here.
"the quieter you become, the more you are able to hear.."
Lets begin.. :D
- Use this fuzzer as the starting point.
Fuzzer:
- That fuzzer will overwrite the SEH buffer with the address of the VBAJET32.dll that have a POP POP RETN command inside. Lets try to execute it. But don't forget to place a breakpoint on the address of the commands at 0F9A196A.
- Execute it then see what happen in the SEH Chain.
- It contains the VBAJET32 address. Then lets generate the a payload using the default bad character 0x00 0x0a 0x0d.
- Insert it to our fuzzer.
Fuzzer:
- SEH pointed the wrong address, SEH supposed to point on the VBAJET32.dll address that we've placed. The problem is definitely because of the payload that we've generate. Usually this happen when a bad characters is exist on our payload. Lets search it.
- First step, we need to generate a dummy code contains all hex character start from 00 to FF. To do it we can use this perl script.
Script:
# perl generatecodes.pl (badchar1),(badchar2),(badchar3),...(badcharn)
example
# perl generatecodes.pl 00,0a,0b,0c,0d
- Ok, generate it.
# perl generatecodes.pl 00,0a,0d
- Next, we must enter this code line by line. This will make us easier to find bad character. Also this will make the results more accurate although it waste a lot of time. But with regular training, this can be done less than 5 minutes.
- Ok, lets insert the first line to the fuzzer.
Spoiler:
- Good, it contain the right value, VBAJET32. This means the first line doesn't contain a bad character.
- Insert the second line to the fuzzer.
Fuzzer:
- SEH contain the wrong value. This means that in the second line there is one or more bad character inside. To make the searching results more accurate, divide the second line into two.
"\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
will be
"\x12\x13\x14\x15\x16\x17\x18\x19" and "\x1a\x1b\x1c\x1d\x1e\x1f\x20"
- Insert the first part to the fuzzer.
Spoiler:
- Ok, the first part doesn't contain any bad character. Lets continue to the second part. To make the search more precise. Lets divide the second part into two parts too.
"\x1a\x1b\x1c\x1d\x1e\x1f\x20"
will be
"\x1a\x1b\x1c\x1d\x1e\x1f" and "\x20"
- The division can be whatever you like. No specific criteria to do that. But myself I like to divide the words and number.
- Ok, lets insert the first section of the second part to the fuzzer.
Fuzzer:
- It still contain the right value. This means the second section of the second parts is the bad character that is \x20.
- Lets generate the dummy code again with the addition of \x20 as a bad character.
Code:
Fuzzer:
- Good, looks like we've found the bad characters from this application. But, to make sure that everythings going right we will compare the data in the buffer memory and the dummies sent. This process will find the bad character hidden inside the buffer memory of the application.
- To do this we must compare the data inside the buffer memory of the application after it is attacked by the fuzzer and the dummy data we've generated and inserted to the fuzzer before.
- Ok, place the breakpoint again then execute the fuzzer. OllyDbg will break the process when the application trying to access VBAJET32.dll. Then press Shift+F9. OllyDbg will bring us to the POP POP RETN command.
- Press F7 three times, this will bring us to the JMP SHORT command.
- Press F7 once again, this will bring us the location of 16 bytes NOP before the dummy code.
- As you can see above. We can see the beginning of the dummy code, "0102".
- Next is dumping the content of the buffer where the dummy code start.
- Click on the 0102 then right click > Follow in Dump > Selection
- Block all character start from 01 to FF then right click > Binary > Binary Copy
- After that paste to the text editor like gedit, kwrite, geany, anjuta, etc. Save with the name you like.txt.
Hex:
# perl generatecodes.pl 00,0a,0d,20 > dummy.txt
- Save this perl script to compare the value inside that two files.
Compare:
# perl comparememory.pl binary.txt dummy.txt
- The value of \x25 is substituted with \x57. Lets see what happen in the buffer at that point.
- Value 25, 26 and 27 is missing. This means one of them is a bad character.
- To know what is the exact bad character we can exclude them one by one, generate the dummy code again using the data excluded as a bad character, sent to the application then compare again the dummy data sent and the data on the buffer memory.
- If there's no difference between them after comparation, that means the excluded character is the bad character.
The bad character is 25, you can try it yourself if you want.. :)
rest of the exploitation process here.
"the quieter you become, the more you are able to hear.."
3 comments:
just a copy of Grey Corner
copy of Grey Corner ??
yudhi, meybe that he mean http://www.thegreycorner.com/2010/01/seh-stack-based-windows-buffer-overflow.html
Post a Comment