Java Security Advent Calendar 2019

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import org.jdom2.Content;
import org.jdom2.Document;
import org.jdom2.JDOMException;
import org.jdom2.input.SAXBuilder;

public class ImportDocument {
  // This function extracts the text of an OpenOffice document
  public static String extractString() throws IOException, JDOMException {
    File initialFile = new File("uploaded_office_doc.odt");
    InputStream in = new FileInputStream(initialFile);
    final ZipInputStream zis = new ZipInputStream(in);
    ZipEntry entry;
    List<Content> content = null;
    while ((entry = zis.getNextEntry()) != null) {
      if (entry.getName().equals("content.xml")) {
        final SAXBuilder sax = new org.jdom2.input.SAXBuilder();
        sax.setFeature("http://javax.xml.XMLConstants/feature/secure-processing",true);
        Document doc = sax.build(zis);
        content = doc.getContent();
        zis.close();
        break;
      }
    }
    StringBuilder sb = new StringBuilder();
    if (content != null){
      for(Content item : content){
        sb.append(item.getValue());
      }
    }
    return sb.toString();
  }
}

The function extractString opens an OpenOffice document which was previously uploaded by an attacker and extracts the text from it. An OpenOffice document is actually a ZIP file which contains multiple resources. Amongst other things the document contains a file named content.xml which contains the text information in XML representation. This file is parsed by the method org.jdom2.input.SAXBuilder.build() which is vulnerable to XXE injection. We can exploit this XXE by adding the following DOCTYPE declaration to the XML document and reference the XXE entity in the document. This will insert the contents of the file /etc/passwd into the document.

1
2
3
4


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT text ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


import org.json.*;

public class MainController{
    private static String[] parseJsonAsArray(String rawJson, String field) {
        JSONObject obj = new JSONObject(rawJson);
        JSONArray arrJson = obj.getJSONArray(field);
        String[] arr = new String[arrJson.length()];
        for (int i = 0; i < arrJson.length(); i++){
            arr[i] = arrJson.getString(i);
        }
        return arr;
    }

    private static String parseJsonAsString(String rawJson, String field){
        JSONObject obj = new JSONObject(rawJson);
        return obj.getString(field);
    }

    //rawJson is user-controlled.
    public MainController(String rawJson) {
        this(parseJsonAsString(rawJson, "controller"), parseJsonAsString(rawJson, "task"), parseJsonAsArray(rawJson, "data"));
    }

    private MainController(String controllerName, String task, String... data){
        try {
            Object controller = !controllerName.equals("MainController") ? Class.forName(controllerName).getConstructor(String[].class).newInstance((Object) data) : this;
            System.out.println(controller.getClass().getMethod(task));
            controller.getClass().getMethod(task).invoke(controller);
        } catch (Exception e1) {
            try {
                String log = "# [ERROR] Exception with data: " + data + " with exception " + e1;
                System.err.println(log);
                // DONE: VulnApp Security Bug #23517: Strip all "dots" so file extension does not lead to RCE
                Runtime.getRuntime().exec(new String[]{"java", "-jar", "log4j_custom_dlogger.jar", log.replaceAll(".", "")});
                // TODO: VulnApp Bug #24630: Logging is currently not working in v1.8,
                //       something with an ArgumentException, please have alook at that @peter
            } catch (Exception e2) {
                System.err.println("FATAL ERROR: " + e2);
            }
        }
    }
}

The parameter rawJson in line 20 is user-controlled and parsed as JSON. The data extracted from the JSON string is then passed to this which invokes the second constructor in line 24. Here, the parameter controllerName and data can be misused to instantiate any object and to control the first parameter of a constructor in line 26. In line 28, the parameter task is used as function name that is executed on the previously created object. As a result, we can instantiate any object, control the first argument of the constructor, and we can invoke any function without parameters.
For exploitation, an attacker can instantiate a ProcessBuilder with a shell command like touch hacked.jsp and then call the start() function which invokes the shell command: rawJson={"controller":"java.lang.ProcessBuilder","task":"start","data":["touch","hacked.jsp"]}
Note that the "logging" code in line 34 was a feint and is not vulnerable.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.VelocityContext;
import java.util.HashMap;
import java.util.Map;

public class TemplateRenderer {
  private final VelocityEngine velocity;

  public String renderFragment(String fragment, Map<String,Object> contextParameters){
    velocity = new VelocityEngine();
    velocity.init();
    VelocityContext context =  new VelocityContext(contextParameters);
    StringWriter tempWriter = new StringWriter(fragment.length());
    velocity.evaluate(context, tempWriter, "renderFragment", fragment);
    return tempWriter.toString();
  }

  public String render(HttpServletRequest req, HttpServletResponse res){
    Map<String, Object> hm = new HashMap<String, Object>();
    hm.put("user", req.getParameter("user"));
    String template = req.getParameter("temp");
    String rendered = renderFragment(template,hm);
    res.getWriter().println(rendered);
  }
}

A temp parameter is received in line 23 and passed to the renderFragment() function in line 24. Here, the first argument fragment leads to a Code Injection vulnerability in the Velocity template. In line 16, the fragment (template) is evaluated as Java code by Velocity. An exploitation is not that easy though. The limitation of this Template Injection is that the attacker can't execute Java code directly. However, Java reflection can be used to access interesting Java classes and to finally execute arbitrary shell commands:

1
2
3


user=&temp=#set($s="")#set($stringClass=$s.getClass()
   .forName("java.lang.Runtime").getRuntime()
   .exec("touch hacked.jsp"))$stringClass

(Payload source)

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import javax.servlet.http.*;

public class Login extends HttpServlet {
  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) {
    String url = request.getParameter("url");
    //only relative urls are allowed!
    if (url.startsWith("/")) {
      response.sendRedirect(url);
    }
  }
}

This code challenge receives the user input via the GET or POST parameter url in line 7. The url parameter can be used to exploit an open redirect vulnerability. The redirect happens in line 10 if url starts with /. However, a URI starting with 2 slashes ( //attacker.org ) is not a relative URI but an absolute URI without a scheme. Therefore, the intended check if the URI is relative can be bypassed with the url parameter //attacker.org.

Finally, the Location response header looks like:

Location: //attacker.org

and the server redirects the victim to attacker.org.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


import javax.servlet.http.HttpServletRequest;
import java.util.Enumeration;
 
public class Request {
  public static String toString(HttpServletRequest req) {
    StringBuilder sb = new StringBuilder();
    String delimiter = req.getParameter("delim");
    Enumeration<String> names = req.getParameterNames();
    while (names.hasMoreElements()) {
      String name = names.nextElement();
      if (!name.equals("delim")) {
        sb.append("<b>" + name + "</b>:<br>");
        String[] values = req.getParameterValues(name);
        for (String val : values) {
          sb.append(val);
          sb.append(delimiter);
          sb.append("<br>");
        }
      }
    }

    return sb.toString();
  }
}

In this code challenge the function toString iterates over all HTTP parameters and formats them into HTML representation. In real world scenarios this can be used for logging purposes. In line 7 the value delimiter is received and is appended in line 16 to the StringBuilder instance after each parameter value. A denial of service issue may arise due to the internals of java.util.StringBuilder. By default the StringBuilder object is initialized with an array of size 16. Each time a new value is appended, the StringBuilder instance checks if the data fits into the array. If not, the size of the array is doubled. In this case there is a large amplification which can cause the Java heap to run out of memory. By default Apache Tomcat has a 2MB limit for POST requests and a maximum amount of 10000 parameters. If we submit a very large value for parameter delim (e.g. 1.8 MB) in combination of an array with multiple (e.g. 10000) HTTP parameters we have a maximum amplification of the factor ~20000, considering the StringBuilder internals.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import java.io.*;
import java.nio.file.*;
import javax.servlet.http.*;

public class ReadFile extends HttpServlet {
  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) throws IOException{
    try{
      String url = request.getParameter("url");
      String data = new String(Files.readAllBytes(Paths.get(url)));
    }
    catch (IOException e){
      PrintWriter out = response.getWriter();
      out.print("File not found");
      out.flush();
    }
    //proceed with code
  }
}

In line 9 untrusted user input is received from the parameter url. A java.nio.file.Path instance is created from the given value and the contents of that file are read by the method java.nio.file.Files.readAllBytes(). This functionality can be used to read arbitrary files through path traversal. The contents of the file are not reflected into the response of the request, so it is not possible to access the content. However, by sending the value /dev/urandom the application can be interrupted because the method Files.readAllBytes() will not terminate until the Java heap is out of memory. This leads to an infinite file read and finally to a memory exhaustion (DoS) which is not catched by the IOException handler.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import com.fasterxml.jackson.core.*;
import javax.servlet.http.*;
import java.io.*;
 
public class ApiCache extends HttpServlet {
 
  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) throws IOException{
    storeJson(request, "/tmp/getUserInformation.json");
  }
 
  protected void doGet(HttpServletRequest request,
                       HttpServletResponse response){
    loadJson();
  }
 
  public static void loadJson(){
      // Deserialize to an HashMap object with Jackson's JsonParser and read the first 2 entries of the file.
  }
 
  public static void storeJson(HttpServletRequest request, String filename) throws IOException {
    JsonFactory jsonobject = new JsonFactory();
    JsonGenerator jGenerator = jfactory.createGenerator(new File(filename), JsonEncoding.UTF8);
    jGenerator.writeStartObject();
    jGenerator.writeFieldName("username");
    jGenerator.writeRawValue("\"" + request.getParameter("username") + "\"");
    jGenerator.writeFieldName("permission");
    jGenerator.writeRawValue("\"none\"");
    jGenerator.writeEndObject();
    jGenerator.close();
  }
}

In this challenge the username parameter in line 26 is user-controlled and flows into jGenerator.writeRawValue() without sanitization. For example, an attacker could inject the payload ?username=foo","permission":"all which results in:

1
2
3
4
5


{
  "username":"foo",
  "permission":"all",
  "permission":"none"
}

If the JSON object is deserialized in method loadJson() (line 14), the user foo has escalated his privileges to all permissions through a JSON injection. Also, a successful exploitation depends on the implementation of loadJson(). To successfully exploit this issue, the method loadJson() must deserialize only the first occurrence of every key such that the duplicate keys are ignored.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


import java.io.File;
import javax.servlet.http.*;
 
public class GetPath extends HttpServlet {
 
  protected void doGet(HttpServletRequest request,
                       HttpServletResponse response) throws IOException {
    try{
      String icons = request.getParameter("icons");
      String filename = request.getParameter("filename");
 
      File f_icons = new File(icons);
      File f_filename = new File(filename);
 
      if(!icons.equals(f_icons.getName())){
        throw new Exception("File not within target directory!");
      }

      if(!filename.equals(f_filename.getName())){
        throw new Exception("File not within target directory!");
      }

      String toDir = "/var/myapp/data/"+f_icons.getName()+"/";
      File file = new File(toDir, filename);
 
      // Download file...
    }
    catch(Exception e){
      response.sendRedirect("/");
    }
  }
}

The parameter icons from line 9 flows into a File object in line 12. It is validated in line 15, and finally it is concatenated into a file path in line 23. The check in line 15 tries to prevent a path traversal vulnerability by comparing the file name to the parameter icons. The method getName() turns input like /../../../foo.txt into foo.txt and prevents a simple path traversal attack. However, if the input is only .. nothing is removed by getName() and thus it is possible to bypass the security check. In combination with the parameter filename we are able to traverse one directory level higher and can download any file we want there.

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


import java.io.*;
import java.util.regex.*;
import javax.servlet.http.*;
 
public class Validator extends HttpServlet {

  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) throws IOException {
    response.setContentType("text/plain");
    response.setCharacterEncoding("UTF-8");
 
    PrintWriter out = response.getWriter();
    if(isInWhiteList(request.getParameter("whitelist"),request.getParameter("value"))){
      out.print("Value is in whitelist.");
    }
    else{
      out.print("Value is not in whitelist.");
    }
    out.flush();
  }

  public static boolean isInWhiteList(String whitelist, String value){
    Pattern pattern = Pattern.compile("^["+whitelist+"]+");
    Matcher matcher = pattern.matcher(value);
    return matcher.matches();
  }
}

The parameter whitelist from line 13 controls a part of the regular expression pattern in line 23, and the parameter value from line 13 is validated against this expression in line 24. Because we can inject an arbitrary expression and have control over the value that the expression is matched against, we can produce heavy CPU consumption with a complex regular expression (ReDoS). This can lead to a CPU exhaustion and results in a DoS at least in Java 8.

Proof of Concept:

1

whitelist=x]|((((a+)+)+)+)&value=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Can you spot the vulnerability?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@RequestMapping("/webdav")
  public void webdav(HttpServletResponse res, @RequestParam("name") String name) throws IOException {
    res.setContentType("text/xml");
    res.setCharacterEncoding("UTF-8");
    PrintWriter pw = res.getWriter();
    name = name.replace("]]","");
    pw.print("<person>");
    pw.print("<name><![CDATA[" + name.replace(" ","") + "]]></name>");
    pw.print("</person>");
  }

In this code challenge the user input is mapped from the GET or POST parameter name to the function parameter name via the annotation @RequestParam. In line 3 the Content-Type of the response is set to text/xml.

If untrusted user input flows into a response with the Content-Type text/xml an attacker can inject a script tag with the xml namespace attribute "http://www.w3.org/1999/xhtml". The browser interprets the content as JavaScript and executes it. To solve this challenge the attacker first has to escape the CDATA element. The filter can be bypassed by inserting a space bewteen ]]. This space character is stripped by the filter. For all other spaces that are needed for payload the attacker can use tabs.

The following payload can be used to exploit this challenge:

1

test] ]><something%3Ascript%09xmlns%3Asomething%3D"http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml">alert(1)<%2Fsomething%3Ascript><![CDATA[

RIPSTech presents

Java Security Calendar 2019