XSS everywhere

Summary: The "Chat Room" portlet demo that ships with the Apache Pluto Tomcat bundle contains a persistent Cross-Site Scripting (XSS) vulnerability. Specifically, if an attacker can input raw HTML markup into the "Name" or "Message" input fields and submits the form, then the inputted HTML markup will be embedded in the subsequent web page.

Versions Affected:
Apache pluto 3.0.0, 3.0.1

Example:

- Start the Apache Pluto Tomcat bundle
- Visit http://localhost:8080/pluto/portal/Chat%20Room%20Demo
- In the name field, enter:
     <input type="text" value="Name field XSS></input>
- Click Submit
- In the message field, enter:
     <input type="text" value="Message field XSS></input> 

Patch:

diff --git demo/chat-room-demo-portlet/pom.xml demo/chat-room-demo-portlet/pom.xml
index e37d88ddb..1e4b2e4dd 100644
--- demo/chat-room-demo-portlet/pom.xml
+++ demo/chat-room-demo-portlet/pom.xml
@@ -43,6 +43,10 @@
    <version>6.0</version>
    <scope>provided</scope>
   </dependency>
+  <dependency>
+   <groupId>org.apache.commons</groupId>
+   <artifactId>commons-lang3</artifactId>
+  </dependency>
   <!-- for eclipse JSP tooling purposes -->
   <dependency>
    <groupId>javax.servlet.jsp</groupId>
diff --git demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/ChatHistory.java demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/ChatHistory.java
index df82f6a4a..b9f61cf02 100644
--- demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/ChatHistory.java
+++ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/ChatHistory.java
@@ -18,6 +18,8 @@
 
 package org.apache.portals.pluto.demo.chat;
 
+import org.apache.commons.lang3.StringEscapeUtils;
+
 import java.util.ArrayList;
 import java.util.Collections;
 import java.util.List;
@@ -66,7 +68,7 @@ public class ChatHistory {
       StringBuilder txt = new StringBuilder(128);
       synchronized (messages) {
          for (String msg : messages) {
-            txt.append("<p>").append(msg).append("</p>\n");
+            txt.append("<p>").append(StringEscapeUtils.escapeHtml4(msg)).append("</p>\n");
          }
       }
       return txt.toString();
diff --git demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/HelloWorldRender.java demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/HelloWorldRender.java
index 50ac6befd..6eaa6236b 100644
--- demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/HelloWorldRender.java
+++ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/HelloWorldRender.java
@@ -19,6 +19,8 @@
 
 package org.apache.portals.pluto.demo.chat;
 
+import org.apache.commons.lang3.StringEscapeUtils;
+
 import javax.inject.Inject;
 import javax.portlet.annotations.RenderMethod;
 
@@ -48,7 +50,7 @@ public class HelloWorldRender {
       txt.append("<h3>Hello \n");
       // Get the name from the bean. If it hasn't been set, just greet the world.
       if (nameBean.getName() != null) {
-         txt.append(nameBean.getName());
+         txt.append(StringEscapeUtils.escapeHtml4(nameBean.getName()));
       } else {
          txt.append("World\n");
       }

Mitigation:
* Uninstall the ChatRoomDemo war file
- or -
* migrate to version 3.1.0 of the chat-room-demo war file

Later CVE-2019-0186 was assigned to this issue and here is the advisory from apache pluto [1] [2].

Read More

Code execution - Evernote

Summary:
A local file path traversal issue exists in Evernote 7.9 for macOS which allows an attacker to execute arbitrary programs.



Technical observation:
A crafted URI can be used in a note to perform this attack using file:/// as an argument or by traversing to any directory like
(../../../../something.app).

Since Evernote also has a feature of sharing notes, in such a case an attacker could leverage this vulnerability and send crafted notes (.enex) to the victim to perform further attacks.

Patch:
A patch for this issue was released in Evernote 7.10 Beta 1 and 7.9.1 GA for macOS [MACOSNOTE-28840]. CVE-2019-10038 was assigned to this issue.

Read More

Fuzzing Webkit

Summary: While fuzzing webkit the UIProcess subsystem in WebKit, as used in WebKitGTK through 2.23.90 and WebKitGTK+ through 2.22.6 and other products, does not prevent the script dialog size from exceeding the web view size, which allows remote attackers to cause a denial of service (Buffer Overflow) or possibly have unspecified other impact, related to files such as UIProcess/API/gtk/WebKitScriptDialogImpl.cpp and UIProcess/API/gtk/WebKitWebViewGtk.cpp.

System Specifications: My setup was done using Ubuntu 16.04 LTS (my base OS). You can use macOS as well as it has Xcode and Safari by default. If you are using Ubuntu in VM please allocate as much memory and CPUs as possible.

Source Code: You can download webkit source code from here or simply git:

cmd: git clone git://git.webkit.org/WebKit.git webkit 

Before you build webkit make sure to install necessary dependencies, it will require a lot of trial and error while installing the dependencies but perseverance always wins.

cmd: ./Tools/gtk/install-dependencies

Build: To build webkit in macOS use,

cmd: ./Tools/Scripts/build-webkit  

cmd:   mkdir build
          cd build
          CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 ../
          ninja

For ASAN:

Enabling ASAN or MSAN flags to see runtime bugs while building the packages.

cmd: -DCMAKE_CXX_FLAGS="-fsanitize=address  -fsanitize=leak -g"

The compilation of webkit is a time and memory consuming task, make sure you don't run out of patience. Once successfully build you can test by running safari or providing the path of any webkit application.

cmd: ./Tools/Scripts/run-safari

cmd: ./Tools/Scripts/run-webkit-app 

Start fuzzing: From the /build directory you can run fuzzer[1]

cmd: ./fuzz/cert -max_len=1000 -jobs=32 -workers=32 ../fuzz/cert_corpus/

This is one of the methods to fuzz webkit, while running the libFuzzer continuously for multiple days, I did not observe any crashes or hangs. The reason being there are many researchers out there who have fuzzed webkit and reported several bugs in past. (and I've just started..)

Now what?

I started researching more about webkit and found out that "epiphany-browser" utilizes the webkit browser engine, I thought that this browser might have been untouched in terms of fuzzing by a lot of the researchers, hence this time I used AFL to fuzz epiphany. For test-cases, I used domato from google project zero (A DOM fuzzer) to provide input to AFL

Source code: Epiphany Browser

With AFL: 

cmd: mkdir build && cd build 
        CC=afl-gcc meson --default-library=static ../
        AFL_HARDEN=1 ninja

Once done you can start fuzzing epiphany with AFL.

cmd: afl-fuzz -i in/ -o out/ binary @@ 

I let AFL running for 4 days and observed 16 crashes, among those 7 were unique crashes and 4 were hangs (Happy face). I started analyzing the observed hangs. One of the PoC from AFL freezes the epiphany browser by causing the UI process to terminate and below debug traces were left.

(epiphany:4423): Gdk-WARNING **: Native Windows wider or taller than 32767 pixels are not supported
Gdk-Message: Error 71 (Protocol error) dispatching to Wayland display

Looking at the above traces I came to the conclusion that the native UI window cannot open dialog boxes more than 32767 pixels.

Rather than using AFL PoC every time, I generated my own test-case as I just needed to pass some random characters in native UI windows to produce this hang.

<script>
   var a = '';
   for (var i = 1; i <= 5000; i++)
    {
       a += 'A';
    }
   alert(a);
</script>

You can run the above JS on a vulnerable version of epiphany browser to test this issue. I went ahead and found that WebKitScriptDialogGtk.cpp along with WebKitScriptDialogImpl.cpp &  WebKitWebViewGtk.cpp from webkit source code are responsible for this issue and figured out the below snippet of code from WebKitScriptDialogGtk.cpp was the source of the vulnerability.

static GtkWidget* webkitWebViewCreateJavaScriptDialog(WebKitWebView* webView, GtkMessageType type, GtkButtonsType buttons, int defaultResponse, const char* primaryText, const char* secondaryText = nullptr)
{
    GtkWidget* parent = gtk_widget_get_toplevel(GTK_WIDGET(webView));
    GtkWidget* dialog = gtk_message_dialog_new(WebCore::widgetIsOnscreenToplevelWindow(parent) ? GTK_WINDOW(parent) : nullptr,
        GTK_DIALOG_DESTROY_WITH_PARENT, type, buttons, "%s", primaryText);
    if (secondaryText)
        gtk_message_dialog_format_secondary_text(GTK_MESSAGE_DIALOG(dialog), "%s", secondaryText);
    GUniquePtr<char> title(g_strdup_printf("JavaScript - %s", webkitWebViewGetPage(webView).pageLoadState().url().utf8().data()));
    gtk_window_set_title(GTK_WINDOW(dialog), title.get());
    if (buttons != GTK_BUTTONS_NONE)
        gtk_dialog_set_default_response(GTK_DIALOG(dialog), defaultResponse);

    return dialog;
}

After that I submitted this bug in webkit, the issue was patched and  CVE-2019-8375 was assigned which states "This allows remote attackers to cause a denial of service (Buffer Overflow) or possibly have unspecified other impact."

Metasploit module: It is a denial of service vulnerability and you can simply use RemoteHTTPServer to write a quick MSF module for this.
In the past, I have created BFuzz (DOM Fuzzer) which automates the task of generating multiple test-cases using domato, which can be further used to fuzz browsers of your choice.

However, there are still 7 unique crashes and 3 hangs which I haven't analyzed yet, that may be covered in one of my upcoming blog posts.

Read More

Say OK Google!

Hi Internet,

Summary: The inbuilt applock of Dr. Safety can be bypassed locally by saying "OK Google" and then viewing the activity pane, which was left unpatched by TrendMicro.

Img Src: https://lh6.ggpht.com/

After finding Same Origin Policy Bypass in Trend Micro Dr. Safety for Android (Consumer), I started digging more on this application. It also has a feature of applock which enables users to lock their respective applications via secure pin or fingerprint.

This may not be a great bug because only a local attacker can exploit the issue, but the steps to reproduce this issue was innovative (personal opinion).

Steps to reproduce:
1. Lock all your apps using Dr. Safety app lock. (Google, Gmail, Slack etc.)
2. Once all applications are locked by Dr. Safety app lock, Say OK Google. (Assuming your OK Google service is also locked it will ask for pin or pattern).
3. But continue saying such as "My emails from Sanjay"
4. In background "OK Google" replies "This is what i found ...." (However, still we cant see the data because Dr. Safety app is asking for pin/pattern #Step2).
5. Now, just try closing that window by using activity pane. (Which actually allows you to close all running apps).
6. Bingo! In app preview you will see the glimpse of email from "Sanjay" or Mr.XYZ. Below PoC for reference.

 

I believe from a malicious attacker's perspective, the application still fails to prevent exposure of other applications which are being locked by Dr Safety, thus leaking such confidential information, which in my opinion is a concern.

I went ahead and spent some time by analyzing the APK file and found AppLockMain.xml file can be responsible for this issue.

Recommendation:
As a recommendation, I can suggest that when the user accesses the activity pane using the hardware/software buttons on the phone, the Dr. Safety app can detect if it's running in the background and use a screen overlay of it's own to mask the other applications which are being display in the activity pane.

Alternative applock:
and guess what? there is an alternative app in playstore which also locks the recent app list (activity pane) in the same fashion which i mentioned above. So Norton App Lock from play store allows users to lock their activity pane also in such case the above attack scenario will be failed.

Trend Micro security team left this issue unpatched and replied:
* User could easily clear all recent activities.
* On Android 7 and above, users could easily dismiss the ‘draw over other apps’ in status bar, so the page blocked ‘Recent’ will be dismissed. Thus, we could not provide this enhancement efficiently.
 
I hope you like the read.

Thank you

Dhiraj

Read More

Fuzzing HTTP Server (PDF.js)

Hi Internet

Summary: While fuzzing Mozilla PDF.js a format string vulnerability it was observed that the development server used in PDF.js gets crash when a malformed URI(bad request) is sent.

PS: The patch for the path traversal bug which was found perviously gave rise to this issue.

I have used boofuzz in the case to fuzz PDF.js, boofuzz is a fork of and the successor to the venerable sulley fuzzing framework, for installation you can simply use pip.

pip install boofuzz

Then,

session = Session(
    target=Target(
        connection=SocketConnection("127.0.0.1", 8888, proto='tcp')))

In boofuzz each message starts with an s_initialize()

s_initialize(name="Request")
    with s_block("Request-Line"):
        s_group("Method", ['GET'])
        s_string("/", name='Request-URI')
        s_string('HTTP/1.1', name='HTTP-Version')

Vulnerable code in PDF.js (webserver.js):

  _handler: function (req, res) {
     var url = req.url.replace(/\/\//g, '/');
     var urlParts = /([^?]*)((?:\?(.*))?)/.exec(url);
     // guard against directory traversal attacks,
     // e.g. /../../../../../../../etc/passwd
     // which let you make GET requests for files outside of this.root
     var pathPart = path.normalize(decodeURI(urlParts[1]));

If you see the bold part of the above code the PDF.js did not have any guard for malformed URI sent in various methods.

However, the fuzzer ran for an hour and it was observed that the HTTP server of PDF.js can't handle malformed strings and server gets crash. While fuzzing with boofuzz its better to start Wireshark on 'lo' to see all the fuzzed request which are sent to the server. I found /%s%s%s was used in this case.

curl -v -X GET 127.0.0.1:8888/%s%s%s

The PDF.js server gets crash and below traces are left.

Server running at http://localhost:8888/
[12:16:22] 'server' errored after 1.01 h
[12:16:22] URIError: URI malformed
at decodeURI ()
at WebServer._handler (/Users/Dhiraj/Desktop/pdf.js/test/webserver.js:86:35)
at Server.emit (events.js:188:13)
at Server.EventEmitter.emit (domain.js:459:23)
at parserOnIncoming (_http_server.js:676:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:113:17)

However, the bug was submitted to Mozilla and a patch was deployed for same.

Patch code in PDF.js (webserver.js):

    try {
       // Guard against directory traversal attacks such as
       // `/../../../../../../../etc/passwd`, which let you make GET requests
       // for files outside of `this.root`.
       var pathPart = path.normalize(decodeURI(urlParts[1]));
     } catch (ex) {
       // If the URI cannot be decoded, a `URIError` is thrown. This happens for
       // malformed URIs such as `http://localhost:8888/%s%s` and should be
       // handled as a bad request.
       res.writeHead(400);
       res.end('Bad request', 'utf8');
       return;
     }
     var queryPart = urlParts[3];
     var verbose = this.verbose;

If you are a mozillian and you like my work towards PDF.js, don't hesitate to vouch me :) Hope you like the read.
https://mozillians.org/en-US/u/Dhiraj_Mishra/

Thank you

Dhiraj

Read More