Monday 29 November 2021

Play the Opera Please

Prior approval are taken from Opera security team before disclosing this issue!

Before we get started there are few things which we need to understand such as,

Value added service (VAS): Value added services (VAS) is a popular telecommunications term for non-core services, example: (Caller-tunes, Missed call alerts, Online gaming etc).

GGSN: The gateway GPRS support node (GGSN) is a main core component, GGSN is responsible for the interworking between the GPRS network and external packet, basically this is a routing device.

HTTP header enrichment (HE Process): HTTP header enrichment is the process of adding data fields in the HTTP header. This is commonly used in mobile networks by adding user and device identifiers in HTTP requests such as IMEI, IMSI, MSISDN or other data to identify subscriber or mobile device details[1].

As per my understanding during a VAS subscription process, GGSN picks up the MSISDN from HTTP header to subscribe end users, the idea is to abuse HTTP header enrichment process via Opera mini browser which could lead to fraudulent VAS activation.

Why Opera mini? Opera mini is famous for data compression (data saving mode) although it supports three types of data savings compressions modes. direct, extreme and high.
Once the request is initiated and routed by GGSN all communication happens in HTTPS, hence GGSN will not be familiar with the source MSISDN, because there is no header enrichment process, Opera turbo server establish a secure session to perform rest of the process during the subscription. In this case GGSN acts as a routing device and fails to perform HE process (Because HE can only be performed on HTTP protocol but Opera mini creates an HTTPS based session).

Post this if we  navigated to snif the packets via wireshark the source IP would be our public IP and destination hits to opera turbo servers such as `` rather than

Having said that, after countless assessment on the subscription process via opera mini, I found one `ping`  request which is generated via opera mini, when its is open for the first time after clearing the cache and temp data of the browser. It was observed, that ping request is responsible for taking MSISDN and creating the session for entire flow.

Injecting MSISDN headers in this request with the victims MSISDN, the session was established by victims number with opera turbo server and now you can impersonate victim and subscribe for any VAS service to deduct his/her digital money. With a successful subscription using the above steps and server log it was concluded that opera turbo servers don’t validate/filter certain injected HTTP headers which leads to activation of VAS services.

Patch: Opera turbo stops forwarding such injected HTTP headers and CVE-2018-19825 was assigned to this which states “Lack of filtering of certain HTTP headers could lead to fraudulent VAS activation."

Thursday 11 February 2021

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?

Tuesday 13 October 2020

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оо* --> (#1 Fake
http*://** --> (#2 Real
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.

Thursday 26 March 2020

Stealing videos from vlc

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 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]

Wednesday 4 March 2020

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 ; 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 [].

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 [] a script which contains some standard ubuntu packages so you dont get much dependence issues while compiling any target. Keep fuzzing :)