Wednesday, 13 February 2019

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:

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.

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

Monday, 21 January 2019

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

session = Session(
        connection=SocketConnection("", 8888, proto='tcp')))
In boofuzz each message starts with an s_initialize()
    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
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.end('Bad request', 'utf8');
     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.

Thank you

Tuesday, 15 January 2019

I swiped right

Hi Internet,

Summary: By using multi-gesture trackpad along with Safari browser in MacBook Pro, one can view sensitive data which is cached in your Safari browser. (Note: This is not a back button browsing vulnerability)

I figured out this issue while playing around with Safari browser, looks like the most recent activity of any authenticated or un-authenticated website is stored in cache of Safari browser and by taking the advantage of multi-gesture trackpad we can retrieve any or all information about that activity.

Looks like Apple provides a feature in trackpad which allows users to swipe between the pages or applications. It also allows you to tap, swipe, pinch, or spread one or more fingers to perform useful actions but seems they forgot to add some security measures in this.

Trackpad settings

Steps to reproduce:
1. Open safari browser (v12.0.2 (14606.3.4) was used in this case)
2. Login to any dynamic website (I've used
3. Perform your dynamic activity
4. Logout (But don't close your safari browser)
5. Now swipe right

You would actually see your recent data, between the pages. I've also created a video proof-of-concept for same.

Apple says: After reviewing your report we do not see any actual security implications. (I think this was the lamest vendor response).

But, I feel like this is an interesting issue which can be exploited by local attacker. Also this only works with safari browser. I hope you like the read.

Thank you

Sunday, 6 January 2019

Metadata and potential password leak in aria2

Hi Internet,

Summary: aria2 is a lightweight multi-protocol command-line utility, which store's "HTTP Basic Authentication" username and password in a file when `--log` attribute is used.

This issue was observed while performing the code review of aria2, However the file was responsible for this issue, below is the vulnerable code :

1. It was observed that URL's which gets downloaded via `--log=` attribute stored sensitive information.
2. In combination with HTTP authentication a username and password can be part of the URL.
    `aria2c --log=file`

In such case the log file contains password as well, sometimes URL's may contain secret tokens, e.g. private file shared on a file hosting service. In general storing metadata at unexpected places should be avoided, rest other utility like cURL was patched to this issue, it uses HTTP digest authentication mechanism for such case.

Moving further this issue was patched and such information will be masked in latest versions of aria2. This is also similar to when URL of downloads gets stored via filesystem attributes on systems that support unix extended attributes. You can see these attributes on Linux systems by running getfattr -d [filename]

Later CVE-2019-3500 was assigned to this issue, hope you like the read.

Thank you

Friday, 23 November 2018

Path traversal in mozilla pdf.js

Hi Internet,

Summary: A path traversal issue was observed in Mozilla PDF.js which is a PDF reader in JavaScript. (This issue is unpatched)

This issue was observed while code review of PDF.js (gulpfile.js)

PDF.js is built into version 19+ of firefox and a chrome extension is also available on chrome web store. To install and get a local copy of PDF.js here are the below steps :

Then navigate to

I've used the attribute --path-as-is from cURL to verify this issue.

This was reported to mozilla via bugzilla but team says "The server with pdf.js is intended to be a development server and should not be exposed to public networks. I suppose we could update the docs to state that." and a upstream issue was filed against this[1].

Thank you