The "P" in Telegram stands for Privacy

Summary: While understanding the implementation of various security and privacy measures in telegram, I identified that telegram fails again in terms of handling the users data. My initial study started with understanding how self-destructing messages work in the secret chats option, telegram says that "The clock starts ticking the moment the message is displayed on the recipient's screen (gets two check marks). As soon as the time runs out, the message disappears from both devices." 

 

Telegram which has 500 million active users suffers from a logical bug exists in telegram for macOS (7.3 (211334) Stable) which stores the local copy of received message (audio/video) on a custom path even after those messages are deleted/disappeared from the secret chat.

Technical analysis: Open telegram for macOS, send a recorded audio/video message in normal chat, the application leaks the sandbox path where the recorded message is stored in ".mp4" file.

In my case the path was (/var/folders/x7/khjtxvbn0lzgjyy9xzc18z100000gn/T/). While performing the same task under secret chat option the MediaResourceData(path://) URI was not leaked but the recorded audio/video message still gets stored on the above path.

 
In the video proof-of-concept the user receives a self-destructed message in the secret chat option, which gets stored even after the message is self-destructed.

 

Bonus: The above mentioned version of telegram for macOS stores local passcode in plain text, below is the video proof-of-concept.

 

Both the vulnerabilities was patched in version 7.4 (212543) Stable and 3000 EURO bounty was awarded. In past I've identified multiple vulnerabilities under Telegram you can read them here. Later today Fri 12 Feb 12:15 PM, CVE-2021-27204 & CVE-2021-27205 was assigned. What next?

Use Signal

— Elon Musk (@elonmusk) January 7, 2021

Read More

Bypassing Trend Micro Web Threat Protection via Punycode

Summary: It was identified that Trend Micro web threat protection can be bypassed using puny-code and was tested under macOS 10.15.4 (19E287).

Technical Analysis: Trend Micro antivirus for macOS has an additional feature called web threat protection which has three main components. [1]

Enable Web Threat Protection: When enabled, web threat protection starts checking the reputation scores of user requested web sites. Depending on the results, Trend Micro security (for Macintosh) will either deny or allow access to the requested web site. Enabling or disabling web threat protection from this screen enables or disables web threat protection on the protection status screen.

Protection Strength: Select High, Medium, or Low.

Approved Websites: Contains a list of user or administrator approved web sites. Security (for Macintosh) will not block web sites that are on the approved websites list.

We will be focusing on "approved websites" component which allows users or administrators to add URLs which needs to be blocked, having said that it was observed that this functionality can be abused by puny-code and leads to WTP bypass. 

http*://*.gооgle.com/* --> (#1 Fake google.com)
http*://*.google.com/* --> (#2 Real google.com)

The above #1 utilizes puny-code with the combination of english and russian characters when such URLs are added under web threat protection, Trend Micro antivirus cannot render puny-code. Hence user will still be able to browse those blocked URLs, below is the video proof of concept demonstratingthis attack.



Remediation: Trend Micro security team fixed this vulnerablity in Antivirus for Mac (2021) by URL filtering for such domains or a puny-code domain name conversion. A offical advisory was published and CVE-2020-25779 was assigned to this.

Read More

Stealing videos from vlc

Summary:
VLC for iOS was vulnerable to an unauthenticated insecure direct object reference (IDOR) which could allow a local attacker to steal media from the storage by just navigating to the source URL/IP.

This was possible by abusing a functionality in the iOS application for VLC, which allows a user to share files with others over WiFi. This can be simply done by enabling "Network > Sharing via WiFi" and the web-server for this functionality works on port 80(http) protocol.

Technical analysis:
Let's assume a scenario where Bob & Alice are sharing a video over the WiFi using vlc-iOS, Eve could perform this attack by crawling the source IP address of Bob which would list the URL's of the videos shared between Bob & Alice.

Having said that, navigating to those URL's Eve could simply steal the video without Bob's knowledge which successfully leads to unauthenticated IDOR. 

In the below image, Bob's IP is 192.168.1.135 and the hierarchy of stored videos in Bob's phone would look like,

Such things can be crawled via burpsuite or you can use python scrapy to extract the URL's from the host and download the videos.

Mitigation from VLC Security team:
They implemented a user-friendly authentication mechanism on VLC iOS web server for WiFi Sharing. Passcode authentication is enabled when VLC's passcode setting is enabled and the user uses the passcode that he set in VLC's settings to log into Wifi Sharing.

This was reported on 2nd Jan 2019 and patched on 10th Feb 2020 whereas fixed version was publicly released in March 2020. Post mitigation VLC published an advisory for this which you can view here. Aside this issue was accepted for bounty on The Internet.

Update Friday, 22 May 2020: Advisory from VLC Security[1]

Read More

Fuzzing VIM

AAAAAAAAAA....: It's almost a year now I started with fuzzing and discovered multiple bugs. The most commonly software which I've fuzzed so far includes Xpdf, VIM, PuTTY, WebKit, LibreOffice, Glibc etc. In this post I'll be demonstrating fuzzing VIM (Regex engine) through AFL++ a.k.a american fuzzy lop.

Technical Details: VIM a.k.a Vi IMproved has 12 different editing modes which can be utilized for fuzzing. Vim has lots of potential for finding bugs with AFL. One of the bug which I found while fuzzing VIM was CVE-2019-20079, I would also like to thank Dominique Pelle for this.

[+] Git clone VIM
cmd$ git clone https://github.com/vim/vim.git ; cd vim

[+] Compile and Make VIM with AFL++ 
cmd$ CC=afl-clang-fast CXX=afl-clang-fast++ ./configure --with-features=huge --enable-gui=none
cmd$ make -j4 ; cd src/

[+] Feed Corpus
cmd$ mkdir corpus ; mkdir output 
cmd$ echo "a*b\+\|[0-9]\|\d{1,9}" > corpus/1 ; echo "^\d{1,10}$" > corpus/2

[+] Fuzzing VIM
cmd$ afl-fuzz -m none -i corpus -o output ./vim -u NONE -X -Z -e -s -S @@ -c ':qa!'

The above options used -u NONE and -X is to speed up vim startup. Options -e -s are used to make vim silent and to avoid 'MORE' prompt which could block VIM, the option -Z disables the external commands which makes fuzzing safer. I've also created a small bash script which automates the above tasks for you [vimfuzz.sh].

While fuzzing, fuzz it on ram file system to avoid making too much I/O something like:  sudo mount -t tmpfs -o size=6g tmpfs /home/afl-fuzz-user/afl-fuzz. Aside you can use [pack.sh] a script which contains some standard ubuntu packages so you dont get much dependence issues while compiling any target. Keep fuzzing :)

Read More

Sharepoint RCE

Summary:
Few days ago I saw a post from alienvault which says attackers are still exploiting SharePoint vulnerability to attack middle east government organization. Having said that I found Income Tax Department India and MIT Sloan was also vulnerable to CVE-2019-0604 a remote code execution vulnerability which exists in Microsoft SharePoint. A malicious actor could exploit this vulnerability by simply sending a specially crafted SharePoint application package.

Technical analysis:
I found this vulnerability during my free time while I was browsing to ZoomEye to find such component. The application (incometaxindia.gov.in) was found to be vulnerable as it was using SharePoint as a technology to host its service. To verify this I've sent a crafted payload which enable the remote server (incometaxindia.gov.in) to perform a DNS lookup on my burp collaborator. You can do this manual by sending the crafted XML payload or via desharialize.

Aside, MIT Sloan School of Management was also found to be vulnerable with CVE-2019-0604.

Responsible Disclosure:
CERT-In (IncomeTaxIndia):
This was sent to CERT-In on Feb 12, 2020, got initial response by them on Feb 13, 2020. Post that the vulnerability was patch silently.
For MIT:
This was sent to MIT security team on Feb 13, 2020, got initial response by them on Feb 14, 2020. Post that the vulnerability was patch silently on Feb 15, 2020.

Read More