Andmp | A blog about infosec, bug hunting and more!

[Advisory] Unpatched URL Address Bar Spoofing Vulnerability in UC Browser 12.11.2.1184 and UC Browser Mini 12.10.1.1192: With the same old one-liner payload...

noreply@blogger.com (Unknown) — Wed, 8 May 2019 00:40:00 -0700

Brief

I discovered an URL Address Bar spoofing vulnerability in the latest version of the UC Browser 12.11.2.1184 and UC Browser Mini 12.10.1.1192 that have over 500mn and 100mn installs each respectively, as per Playstore.

This vulnerability allows any attacker to pose (his phishing domain) as the targeted site, for example, a domain blogspot.com can pretend to be facebook.com, by simply making an user visit www.google.com.blogspot.com/?q=www.facebook.com

Description

Previously, I wrote about this issue affecting Xiaomi Mi and Mint browsers, but now UC Browsers (only latest versions) share the same behavior much to my surprise. I find it worth mentioning that some old and other versions of UC Browsers are still not vulnerable to this, which puts me into confusion, which points at the fact that a new feature might have been added to this browser sometime back which is causing this issue.

I have seen a lot of mobile (android) browsers show this behavior, Xiaomi browsers for instance. The main reason behind it is, I guess, these browsers are trying to enhance the User Experience by just displaying the search term for certain URL patterns (search engines and websites like that of Yahoo!, Google).

However, while they are trying to display only the content or, data passed by the query parameter, an attacker can leverage this behavior to achieve URL Address Bar spoofing which can lead to efficient phishing attacks at ease.

The fact that their regex rules just match the URL string, or, the URL any user is trying to visit to a whitelist pattern but only check if the URL begins with a string like www.google.com can enable an attacker to bypass this regex check by simply using a subdomain on his domain like www.google.com.blogspot.com and attach the target domain name (which he wants to pose as) to the query portion of this subdomain like ?q=www.facebook.com

The payload being just a one-liner, this can lead to flawless phishing attacks, which is nearly undetectable and is very easy to execute.

Products affected (Versions)

UC Browser 12.11.2.1184 and UC Browser Mini 12.10.1.1192

CVE

Not assigned yet. A request has been sent to Mitre for the same.

Proof of Concept(s)

Payload: www.google.com.attacker.domain/?q=www.facebook.com

UC Browser:

UC Mini:

Reporting Timeline

Issue has been disclosed to their security team sometime back (more than a week ago) but they have now simply simply put an Ignore status on the report.

I have not been given any ETA for a fix from their end.

Taking all this into consideration, I decided to write up on this issue. Interested people can take a look at My Vulnerability Disclosure Policy to learn more about my Vulnerability Disclosure process.

Rewards

$ 0.

Fixed

No, no patches have been released so far to addressed this issue.

Solution

Use stronger regex checks if you want to show search strings in this format in URL bar, or, just remove this feature/behavior entirely so that it doesn't show up in another form later (Mint browser patches were bypassed several times by a fellow researcher because they decided to still keep that feature but with some minor enhancements).

This is how (easily) Indiamart gave away access to their Internal corporate secrets and Dev Instances

noreply@blogger.com (Unknown) — Tue, 23 Apr 2019 08:45:00 -0700

~~I tried to reach out to the IndiaMart folks regarding the security issues I found there but sadly didn't find a proper channel to report them.~~ (with the help of Mohit Kumar, editor of THN, a contact was established with the company today, after all my efforts to reach out to them went in vain) As a result, I 'm taking to Twitter and using this blog post as a medium to reach out to all those top companies who have a large number of users but apparently don't care about secure practices. I hope this blog post raises awareness about such issues, since many companies continue to expose sensitive parts of their infrastructure and customer data, and as such this may serve as an eye-opener for them.

Another interesting point to note here is that AFAIK the Indian NCIIPC or, CERT-IN don't have any full disclosure/even proper responsible disclosure guidelines for reporting issues to private companies, or, any guidelines concerning the time frame that both parties should follow/agree to before disclosing a (reported) issue. In my opinion, they should implement some policies for large companies to follow/adhere to while dealing with security incidents or, reporting security vulnerabilities in their products/infrastructure. So, I would say this way of fully disclosing issues is currently the best option to get things resolved/fixed until some policies regarding the same are brought into effect. This is how I would justify the ethics of this disclosure, if one likes to take that into account. (although this issue was hastily fixed by the company just before publication of this blog post)

Numerous such cases of breach and violent full disclosures can be referred to, to learn from. The most recent being that of Justdial who had an access control bug in an API, where the researcher failed to find a way to responsibly report and disclose the issue to the company which obliged him to publicly fully disclose it. Thus, proper policies and guidelines are needed speaking of reporting and coordinated disclosure of security issues.

Intro

Indiamart is a popular Indian e-commerce platform for B2B as well as B2C sales. It holds an Alexa rank of ~742 (as of writing this)

(From Wikipedia)

In 2014, IndiaMART's portal handled 200 crore in revenue^[6] and 20,000 crore in sales.^[7]^[8]According to a news in Economic Times, as of 2012 IndiaMART was India's largest online marketplace^[9]^[10] and world's second-largest B2B marketplace after Alibaba.^[11]^[12]IndiaMART's e-commerce portal Tolexo was launched in 2014.

In early 2009, the firm received 50 crore Series A round funding from Intel Capital, a part of which was invested in IndiaMART, One97 Communications and Global Talent Track.^[1]^[24]^[25]^[26] In March 2016, it raised Series C Funding from Amadeus Capital Partners and Quona Capital. It is claimed that these funds will be used to scale up the activities of IndiaMART and Tolexo.^[27] In June 2018 IndiaMART has filled draft papers with SEBI to raise $88.24 million through IPO and list on NSE and BSE exchange.^[28]

Hence, we may expect them to be mindful about the security of their sensitive internal infrastructure, taking all this into consideration, but the reality is strikingly, quite different.

Gist

I found my way through various private and sensitive internal infrastructure belonging to Indiamart quite easily. This was accomplished in hardly a few minutes of casual reconnassance, because they hardly followed any security practices, speaking of their overall infrastructure.

Firewalls and VPN only access to internal infrastructure was missing
No authentication required on the most sensitive endpoints
Weak credentials on endpoints and only using basic authentication where one might consider adding 2FA and restrict access to certain internal IP ranges as well.

Think of an external adversary in my place, what would he have done? Is your data secure with Indiamart's security practices (of whose example we got here)?

Issues discovered

Weak credentials on all dev/developer instances/subdomains, letting an external attacker gain easy access to these restricted servers. Ideally, only developers must have access to them, and they should not be kept open on the internet, the company in question should have made these accessible only through a VPN, internally among their employees. But, shockingly they just had a Basic Authentication in place, with these credentials, -- username:password -> admin:admin

Is it that hard to guess the credentials? The username and password both were simply "admin", cool, right?

Finally, their employee wiki or, knowledge base was publicly accessible without any authentication. This is pretty serious. Ask how?

Their internal employee knowledge base/wiki https://kb.indiamart.com allows unauthenticated users to view it, which is meant for their employees and should have been only internally accessible. But this isn't the case, it's accessible publicly and anyone on the internet has access to these corporate secrets of Indiamart.

Through this knowledge base, employees could access internal confidential/sensitive details on how to deal with issues. For example, it contained instructions for lead managers, and so on.

In the past I had also come across an old endpoint in one of their applications that had an access control flaw leading to exposure of user details via victim user's registered phone number, but it seems to be down currently. I no longer retain the details on that.

PoC

For the knowledge base issue, this page for example, details some internal procedures for an Indiamart employee about Login issues,

https://kb.indiamart.com/en/article/client-is-not-receiving-otp-asking-for-usernamepassword-to-login

Company's internal knowledge base is strictly for internal private usage and shouldn't be publicly accessible as such

Issue with Dev instances: Upon trying these credentials,
Username: admin
Password : admin
on these subdomains/Dev instances, one gets access to them,

https://dev-*.indiamart.com

like, https://dev-seller.indiamart.com
https://dev-paywith.indiamart.com

Here, "*" means a wildcard, and can be replaced with paywith, seller and other applications of Indiamart.

How I discovered it?

Using subdomain enumeration I obtained the subdomains (including internal ones that weren't firewalled) of IndiaMart. From here on, it was just a matter of luck and lack of security on the part of Indiamart that led me to discover these vulnerabilities.

SecurityTrails is just a great, and handy tool for performing quick passive reconnaissance and subdomain enumeration like this.

Takeaways

Setup a VPN to shield off your internal infrastructure meant for employee-only access. Don't allow public access to them.
Use strong credentials and 2FA on sensitive and restricted endpoints.

Special Credits

I would like to thank Mohit Kumar of THN, who helped in responsible disclosure of this vulnerability and, a contact was made with an IndiaMart employee who quickly fixed all the issues.

Fix

As of writing this, all issues were temporarily fixed and the dev instances are now inaccessible. However, part of the fix is still insufficient in my opinion.

Rewards

None as of yet. They haven't even sent a proper official acknowledgement letter to thank me for reporting the above issues.

What more could you expect from a ~20 year old multi-million dollar Indian E-commerce giant after reporting severe issues like these?

[Unpatched Vulnerability] CVE-2019-11015: Lock Screen Auth Bypass leading to Sensitive Information Disclosure and an Improper Access Control issue in Xiaomi MIUI OS (latest stable releases affected)

noreply@blogger.com (Unknown) — Wed, 10 Apr 2019 01:50:00 -0700

So, as promised on Twitter, the wait ends, new security vulnerability full disclosure in Xiaomi!

MiSRC team accepted and confirmed this bug for their bug bounty program. I submitted it sometime back. But, this hasn't been fixed yet. Also, I have no idea of when they 're going to patch it, no ETA was provided as usual. So, what about a FULL DISCLOSURE, like I did before, sounds all good right? Alright, IIRC they don't bring fixes in time, so here I 'm spilling the beans about it, before they silently patch it after (n+3) months of reporting the issue.

Disclaimer: I will make a lot of assumptions ahead. Some may not be correct or, feasible in your opinion, use your discretion and change my mind, I would love to know your opinions on it!

Some Assumptions

Attacker has physical access to your device.
Victim needs to be an INDIAN
This issue only affects people who have their Region in Additional Settings set to India (although I haven't checked other regions for this issue, maybe more are affected try it out yourself?)
So, are assumptions a bar? judge yourself

Versions affected

Strikingly, yet again those in Indian region are affected by this bug.

Latest stable release 10.1.3.0 (personally tested on), as well as 10.2.3.0 (as per an external source)

Thanks to a friend, Ritam, for helping me confirm this issue on the latest stable release of Pocofone OS as well.

For testing purposes Region can be changed here, in Additional Settings,

Advisory

Mitre assigned CVE-2019-11015 for this issue.

Cause

Wallpaper Carousel feature, that can be turned on by attacker himself upto version 10.*.3.0 (latest stable release) from the Lockscreen itself despite Lockscreen based pass/pin/pattern protection.

This feature is the root cause of this sensitive information disclosure.

The issue actually lies in Glance, a content provider in the Wallpaper Carousel application, I believe.

Whats interesting? Plus, the Proof-of-Concept

There seems to be 2 issues.

1. Missing access control check while Enabling Wallpaper Carousel via Lockscreen: Though, this might not actually be a problem, just more of what I feel - Wallpaper Carousel, that appears on the lockscreen can be disabled on your device, there is an option to do that in the Settings. But, how effective is that? Enabling it isn't password protected on your lockscreen! Can it be an issue, if so in what way?

Follow these steps,

Go to Settings
Search for Wallpaper Carousel/Lockscreen
Turns out you can disable or, enable Wallpaper Carousel through settings.
Is it really an issue? Don't know, just my opinion. Feel free to try to change my mind!
On the version 10.1.3.0 turns out, even after you disable Wallpaper Carousel, there's an option to enable it directly from the Lockscreen, without authentication, also interestingly, Xiaomi makes you agree to some Terms & Conditions (of a 3rd party provider) while Turning on this feature.
So far I said, you can turn on Wallpaper Carousel from lockscreen, but you also have to agree to some T&C to Turn On this feature. You can do that without authentication, even after having disabled it through Settings. Possibly an ACCESS CONTROL issue? Because, an unauthenticated user can Turn On this feature by agreeing to these T&C (possibly of 3rd party content provider) on your behalf.

2. Sensitive Information Disclosure: With the help of Wallpaper Carousel feature, more specifically glance, one can actually get read access as well as write access to user's (current) Clipboard data, and apart from that the attacker can also partially access user's stored social media credentials by abusing Autofill feature.

Follow these Steps to reproduce this issue (PoC)

1. Swipe Lockscreen to right

2. Next, tap on Wallpaper Carousel

3. (Access Control Issue) Enable Wallpaper Carousel from Lockscreen itself

4. Swipe right after enabling Wallpaper Carousel, tap on Wallpaper Carousel again to view this screen. Tap on Read More.

5. This opens a web page something like this. Click on any social buttons that appear on those web pages.

6. From here on, you can expose user's Clipboard Data and partially, user's stored Autofill data for that particular social network.

7. Exposing Autofill data. (example)

Severity

As per Mi Security team, it was marked low, I have to disagree here, and would call it a Medium-risk issue. I have already stated the reasons above for that.

So, what's up with the Clipboard and Autofill (privacy)?

Clipboard shouldn't be accessible to an unauthenticated user via Lockscreen. But as it turns out, in this case, we can access the clipboard and disclose what was there in it. We can EVEN modify it.

Attacker can read what was there in the Clipboard with this vulnerability by abusing the PASTE feature.
Attacker can modify your clipboard content with the COPY/CUT feature as well
Both of the above scenarios have an impact

Autofill

Abusing Autofill feature on Social Login pages, an attacker can successfully expose user's stored email addresses, phone numbers and usernames linked with that social site.

Read more about Android clipboard privacy here, and in fact on one hand Google is working more towards resolving and fixing Clipboard privacy issues in Android Q while on the other we have MIUI OS increasing the potential attack surface. In case of MIUI OS (Indian region/version), even an unauthorised user can bypass Lockscreen based authentication to read and modify your Clipboard data.

Should this data be exposed to an external attacker without authorisation just in case you have enabled Lockscreen based protection/auth?

Reward and Resolution?

For all this, Xiaomi offered me around 480 gold, or, around 45 bucks (in USD), for a bug that affects millions of devices in the Indian region!

They haven't yet paid for this. I won't accept this unfair reward either.

As for resolution, they haven't fixed it yet, nor, given any ETA for fix.

Not just that

There appears to be some issue with Glance of Wallpaper Carousel as well. An access control issue perhaps? That lets an unauthorised person to follow different Trends/Topics for WC. Harmless?

--------------------------------------------------------------------------------------------------------------------------

Update (17th April, 2019)

Right after some media coverage about this issue, Xiaomi silently released a patch for Wallpaper Carousel via Play Store, citing the vulnerability in the changelog of the update.

0day Alert: URL Spoofing Bypassed for latest Mint Browser 1.6.4 by Renwa

noreply@blogger.com (Unknown) — Mon, 8 Apr 2019 19:15:00 -0700

Yesterday, I published about Mint's 1.6.3 being vulnerable to the same flaw that I reported to Xiaomi, even after Xiaomi pushed a fix on the 5th of April, 2019. The fix could be bypassed with little effort neatly.

In a matter of few hours, my friend Renwa bypassed Xiaomi's Mint's latest patch (on PLAYSTORE release) leading to a new 0day.

Who are affected?

Mi Browser and Mint Browser (upto 1.6.4)

Intro

Renwa discovered it and told me about it. This becomes the 2nd zero day discovered in a row in the Mint Browser and Mi Browser.

Renwa found a bypass to the previous patch by Xiaomi team, by simply adding the target domain name to the phishing domain making it the subdomain of the phishing/attacker's domain. Which proved that Xiaomi's patch was insufficient and above all meaningless.

But, the same day he came up with a new exploit which makes use of Unprintable Characters to bypass Xiaomi's new security patch in response to yesterday's 0day.

Trick/Bypass

By using Unprintable Characters %e2%80%8c, appended to the URL query parameter.

Video PoC

PoC

https://www.yahoo.com/entertainment/tagged/kim-kardashian/?p=m.facebook.com%e2%80%8c

(Spoofing m.facebook.com above^)

0day Alert: Bypassing CVE-2019-10875 or, Xiaomi's Mint Browser's URL Spoofing patch: Discovered by Renwa

noreply@blogger.com (Unknown) — Sun, 7 Apr 2019 23:25:00 -0700

A friend and fellow researcher Renwa disclosed a 0day in Xiaomi's Mi and Mint Browsers. He asked me to write about this on my blog since it's very similar to my previous find. He just found a bypass that lets him use the same trick that I used before,

Intro

His exploit/PoC is just the same as mine. Domain stays same, query parameter same. But attacker's domain needs a subdomain same as the name of the query parameter.

That's where he outsmarted Xiaomi's fix with a simple trick.

Who are still affected?

Mi Browser has not received the security patch. Neither has Mint Browser on Xiaomi's App Store.

Shady Security Patch? - Why? because it was so inadequate and easy to bypass!

Too soon? Just after that big news about Xiaomi Browser Vulnerability broke. Makes one question about Xiaomi's overall credibility and security patching. How on earth could someone make such a fix that could be bypassed with just so little an effort? The patch seems shady since it could be bypassed so easily, don't agree? See for yourself. I have published a video PoC of the same.

Renwa pinged me yesterday about his new bypass of Mint Browser's patch in response to my URL spoofing vulnerability that I disclosed a few days back. This got me curious. I was not aware of this because the UPDATED version of Mint (1.6.3) wasn't available on Mi Appstore. I came to know from him that they released the patched version on Google Playstore on the 5th of April, 2019.

His exploit is based on the fact that Xiaomi developers wrote some bad regex rules to patch my previous URL spoofing attack that failed on the onslaught of a new trick to circumvent the same. Was it intentional again :P?

The fix didn't work anyways. Is this how Xiaomi puts things into production? Didn't they test for similar secuity issues or, what? They don't do it for Global products ;) or, what?

Because, they either have started learning regex or, don't know how to patch security issues on their Browser products.

How?

Renwa's 0day utilises the fact that their new Regex rules which were supposed to fix the previous problem, namely, CVE-2019-10875 were not sufficient, not only that, it was not the appropriate measure.

He bypassed their protection by using my previous trick including the target domain in 'q' parameter but, the only thing he included this time, the wittiest part is that it struck his mind what if he changes the *subdomain name* on the phishing domain to the target domain name? Guess what? Their patch failed to prevent this new bypass/attack. Renwa's assumption was right!

New PoC or, attack vector that succeeds my older one

http://google.com.phishing-site.com/?q=google.com that spoofs google.com as an example

Older PoC -> http://phishing-site.com/?q=google.com

Video PoC

Why?

Perhaps Xiaomi security team didn't look deeper into this issue and how attackers could possibly bypass it with minimal changes. Which leads to a 0day, horrifying, isn't it?

Parting Words

I hope they don't make the same mistake again. Patch this 0day and test for similar types of vulnerabilities, adding more security to their Browser apps for the good of all Xiaomi users who rely on their Browsers.

Credits

Renwa.

Xiaomi URL Address Bar spoofing w/ SSL vulnerability or, CVE-2019-10875 - Was it intentionally kept in the global versions by Xiaomi?

noreply@blogger.com (Unknown) — Fri, 5 Apr 2019 03:16:00 -0700

Introduction

Are Chinese device makers on purpose making their software and OS insecure for international markets? Chinese manufacturers have always been well-known to have weaponized their products, and made them vulnerable for attackers or, themselves.

Xiaomi has always been criticized for pestering users with unwanted bloatware apps like Sharetrend (for example, users were forced to download it as part of an update) and it's unwanted ad campaigns. I recently came across this, since finally MIUI 11 will get rid of all those unwanted malicious ads and bloatware, comes as a great relief for users, right? Well, there's more to it than disturbing ad content and things as such.

Speaking of Xiaomi browsers, they lack even the most basic security features like XSS auditors. So, you are always at risk if you are using it. I advise using Chrome rather because it has a good XSS filter.

- Xiaomi Browsers don't have an XSS auditor. - As an example, XSS attacks become simple - Also, common XSS attacks like ones in which you redirect to a javascript/data URI work in Xiaomi, thus making it the least secure, lacking basic security features. For a demo, type javascript:alert(); in Xiaomi browser and hit enter. There is no XSS auditor to protect you against such XSS attacks.

In this case, I found a simple vulnerability in Xiaomi's browser applications. Interestingly, their Security team (MiSRC) confirmed the security issues to be present in their global or, overseas versions and not in their domestic ones. Thus, they inadvertently conveyed the fact that only International versions of their browsers were insecure to this vulnerability, which made me ponder into it.

A question that arises is: Are they targeting International users in particular for efficient phishing campaigns, ad campaigns and distributing unwanted software or, malware? Lots of possibilities with things like this.

2 popular browser (global) versions are affected by this vulnerability (latest global versions), namely:

- Mi Browser (official pre-installed default app for every Xiaomi device), with over millions of installs

- Mint Browser (global versions)

I have been testing MIUI for security bugs, for sometime now and have reported multiple security issues as such on their pre-installed apps and the MIUI OS (as a whole).

However, as for this bug, I would call this an accidental discovery, cause it didn't require much effort but somehow I decided to test a certain feature in their browser which was behaving somewhat abnormally, than expected.

How I discovered the bug?

Firstly, to every person who knows a bit about browsers, it seems pretty much as if they were trying to make the way Google search appears on their browser or, any other search engine's overall UX on their browser better, for which they tried to display only the "search query" on their URL Address bar.

This is the first idea that comes to mind, and indeed, this is how I first hit upon this bug, quite unknowingly, when I once just opened a Google (query) search link in the Mi Browser, and that's how it all started.

This is the sort of link I tried to open in Mi Browser, and ironically this is the PoC for my bug, it shockingly needs almost 0 user interaction to exploit, just make a victim open this link and yeah, that's all to it,

https://www.google.com/?q=www.domain.com

Technical Details

When you try to open a link with a query portion with that URL, Xiaomi's browsers try to display it as search engines would display it in the search bar. This is where the issue arises.

For a link such as this,

https://www.google.com/?q=www.domain.com

The URL bar would display www.domain.com, and I guess that would give you a better search engine experience with this browser.

This is exactly where the problem arises, because the URL bar doesn't display the full URL, and this not only happens in case of popular search engine websites but also with other websites.

Thus, the issue is due to the way the Browser tries to render or, display the URL in the address bar, for example,

https://www.evil.com/?q=www.google.com

The website www.evil.com com can thus pretend to be www.google.com because of the way, the Browser handles the query parameter 'q' of the URL. It just happens with the parameter q.

The browser in such cases would only display the content in the parameter 'q' of the whole URL, but not the whole URL.

Video PoC

Impact?

Mi Browser is the default browser app to open such links, making it susceptible to phishing attacks. This makes it quite feasible to execute successful phishing, and ad campaigns on Mi devices, even for Xiaomi themselves.

Coming back to the previous point, it appeared quite normal for the search term to appear on the browser's search bar, but what if that's the only thing which is being displayed on the Address Bar of the browser. Yep, that's what I observed, when I tapped on the URL Bar, I found only the "www.domain.com" and not the entire domain https://www.google.com/?q=www.domain.com was being displayed.

This initially kept me skeptical but I assumed that this was intended by Xiaomi, keeping (popular and major) search engines in mind, to enhance user feel and feedback, overall UX. But, guess what?

I went ahead to try this oddly interesting behaviour with my own blog's URL (which isn't a popular search engine), guess what happened after that? I managed to reproduce the same behaviour with other websites including mine as well, as shown here,

https://www.andmp.com/?q=www.google.com

And presto!

The URL on the address bar, appeared as www.google.com with that SSL lock in the corner, although I was actually visiting my own blog www.andmp.com. Neato, for phishing?

Xiaomi's blunder or, rather, was this intentional on Xiaomi's part?

My Opinion

The first thing that comes to one's mind after seeing this is, "This is a feature not a bug, right?"

But wait, Xiaomi proved me wrong. Their security team MiSRC acknowledges it as a High Risk security issue for their global users. So, here I am, going a bit further and maybe, I will add more of my personal opinions on what I studied through all this - this maybe biased, and unacceptable to some, but yeah, feel free to skip this part and dive straight into the PoC part, who cares about that after all? This is still unpatched as of now, in the latest release of the Global versions of Mi Browser and Mint Browser as available on Mi Appstore. I haven't been provided any ETA or, such assurances that it would be fixed at the soonest, nothing as such, they just said their Business were repairing or, had fixed it, but truth is even if they have done so, the patched version hasn't made its way to release as of yet.

Up until now, everything I have said or, their security team told me, might sound queer, namely "global users", browser bar including nothing but the search query in the query parameter q, and not the entire URL. So, what's going on?

Xiaomi confirmed that this was the case with their Global variants of Mi Browser. What about Chinese ones, balls wonder? But, according to them, going by their own words, DOMESTIC VERSIONS didn't show this behaviour. Why so?

Maybe, they targeted International Users for malware/unwanted software/ad campaigns. Should we rule out this possibility, given the nature of this bug, it goes unnoticeable (appears quite normal) but it's there?

Chinese (mobile) brands and device makers are infamous for this reason, they don't care about security and privacy, I can give a lot of examples in this regard to prove my point, but let's keep that for another post, shall we?

Let's blame their aggressive marketing, ad campaigns and phishing campaigns for these security issues. Chinese brands have always found new ways to mint money, even after the device has been bought, that maybe in the form of unwanted advertisements popping out of every other native app, harmful bloatware and as such.

But this time, it's a vulnerability that can trick a user into believing that YOU ARE VISITING GOOGLE.COM BUT ACTUALLY YOU ARE VISITING EVIL.COM. However, that isn't my point, look at the simplicity of the bug and how it appears as part of the feature rather than being a vulnerability itself? Well that's how smart Chinese developers seem to be.

Strangely, it's only present in Indian and overseas versions. So, was Xiaomi trying to find a way in which it can effectively distribute malware and set up phishing ad campaigns to trick it's International users who were blindly relying on this default in-built browser, should you trust Xiaomi in that case for anything, even your messages, or, any personal information stored on your phones? Well, this is what Chinese companies are known for internationally.

Given the nature of this bug and how it can pass without being noticed, makes me feel it's intentional. Also, because it was not there in Mi Browser of Chinese versions of MIUI. This is mainly the reason behind my speculations!

Some Attack Scenarios

Some Technical Prospects about this attack, for why this maybe a phishing trap intentionally set by Xiaomi for its foreign users towards whom they targeted their ad campaigns,

As an adversary, one can preferably use a URL shortening service to further make this attack simpler, and more unnoticeable while directly sending links to victim users.

- The PoC or, exploit needs almost zero user interaction. User clicks on the link and off you go!

- Malicious pop ups, they are now easier than ever to execute large-scale successful phishing campaigns!

- Lastly, this seems like a huge flaw left purposefully by Xiaomi who promote such advertisement campaigns by their partners.

This can even effectively be used to trick a user and steal his/her credentials, ask how?

-> Attacker sends you crafted link

-> Thereafter, he adds /?q=target.com to every menu link and everywhere you can click on the phishing page which successfully spoofs every bit of user interaction in the best way possible to give you an as much as real experience with the target web page which might be Google sign in page, just for example.

Xiaomi Security Team's response and Reward

They took sometime in confirming that this bug only affects the Global/overseas versions of their browser applications.

They paid out a very low and unfair bounty, although they are a multi-billion dollar company.

The vulnerability impacts millions of users globally yet the bounty offered as such was, $99 (for Mi Browser) and another $99 (for Mint Browser).

Ridiculous, Xiaomi calls itself a multi-million dollar company and this is how they compensate researchers for their efforts in reality

Peace!

The case of an unusual $10k worth content-based Blind SQLi in a Private Program

noreply@blogger.com (Unknown) — Sun, 31 Mar 2019 11:44:00 -0700

Blind SQL (Structured Query Language) injection is a type of SQL Injection attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.

When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal SQL Injection, the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible.

Using a simple page, which displays an article with given ID as the parameter, the attacker may perform a couple of simple tests to determine if the page is vulnerable to SQL Injection attacks.

Example URL:

http://newspaper.com/items.php?id=2

sends the following query to the database:

SELECT title, description, body FROM items WHERE ID = 2

The attacker may then try to inject a query that returns 'false':

http://newspaper.com/items.php?id=2 and 1=2

Now the SQL query should looks like this:

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

If the web application is vulnerable to SQL Injection, then it probably will not return anything. To make sure, the attacker will inject a query that will return 'true':

http://newspaper.com/items.php?id=2 and 1=1

If the content of the page that returns 'true' is different than that of the page that returns 'false', then the attacker is able to distinguish when the executed query returns true or false.

Once this has been verified, the only limitations are privileges set up by the database administrator, different SQL syntax, and the attacker's imagination

(From Owasp)

--------------

Bummer, did you notice something? Title seemed dope? Couldn't resist looking at it once? Sorry to spoil your excitement mate. (Sed lyf you know!) Anyway, keep reading.

Wtf? Just copy-pasted content?

By the way, did you forget what day it is? (That depends on your timezone though)

Pro Tip: Learn to distinguish clickbaits from legit ones. You 're still young at it and just another noob, much like me.

EASTER EGG DUDE. LIKE SERIOUSLY, WHAT ELSE DID YOU EXPECT ON A DAY LIKE THIS?!

Finally, it makes sense. Right, it does. Just look up your calendar if you still didn't!

TODAY IS THE FIRST DAY OF APRIL! So, 10k figure makes sense I guess, first day of April (1) and 4th month of the year in succession (4 zeros follow).

Anyways, here's a good link to cheer you up! Btw, do you have a similar $10k writeup, do share with me on Twitter ;)

Read more about Blind SQLi here, https://www.owasp.org/index.php/Blind_SQL_Injection

And here we go! Don't get fooled by clickbaits and last but not the least, (a meme stolen from the internet 😆),

Alright, if it disappointed you then you are not alone. Who doesn't want $10k after all? If you read till the end, my clickbait experiment was successful.

Thanks for participating in my April Fool's day clickbait experiment. Another important thing, don't forget to let me know how you felt about it, after reading all this, come on, do say some good words in the comment box or, on Twitter!

How I managed to get an @Google.com email address, bypassing their previous patch!

noreply@blogger.com (Gopal Singh) — Sat, 1 Dec 2018 01:00:00 -0800

The Google Bug Tracker helps them(Google) in tracking through different bugs and security issues, but Gopal, a highly skilled security researcher managed to leverage and pilferage Google through its own issue tracker, isn't it quite creative? A defensive mechanism, since the same tool is used to track and patch security issues was implemented to pervade through Google's protection.

Every organisation have bug trackers, in fact, for example most companies use external ones like Jira bug tracker to track and resolve bugs, so what makes Google's case unique in particular is their custom tailored Issue Tracker and it's features. Security researcher Gopal discovered that although Google had in the past attempted to fix several security issues in their Bug Tracker, yet, it was unsafe and indeed his firm conviction led to him finding a different issue, that can be called a regression but nevertheless, he bypassed Google's previous fix proving the fact - No system can be made "secure" (completely), no matter what amount of patches you make, this again shows the need for bug bounties to motivate and attract highly talented talented individuals as Gopal, and also motivates security researchers to use offensive methods as the one mentioned in this case, and keep trying harder to circumvent all security measures kept in place, even previous patches.

------------------------------------------------------

How I managed to get a Google organisation email, bypassing their previous patch!

I came across this writeup by Alex. I started testing the issue tracker, and I wanted to see if I could somehow manage to get an @google.com Account. In the issue tracker, I found the browse components feature. There were two public issue trackers, I clicked on Android Public Tracker

Bugs reported to Android showed up here. To report a Bug in Android public issue tracker you may simply send an email to-

buganizer-system+componentID@google.com

In this case, android’s component id is 190923.

The issue I made, got listed in the public issue tracker. I got a confirmation email from buganizersystem+my_email@google.com and hence, replies to the email would be directed to-

buganizer-system+componentID+issueID@google.com

I replied to that email and comment was posted in the conversation. I can add google email to see if I can get a confirmation code, to test this I clicked on Forwarding and POP/IMAP in Gmail settings and added the google email to the forwarding email address. I was surprised to see I got a confirmation code in the Android public issue tracker.

There are two parts here, to get a google account. Signup and verification. I can verify a google account, but I could not signup for a @google.com account so my report got closed as Won’t Fix. Bummer!

Then I started visiting every subdomain of Google to see if I could use google.com email to signup and this new signup page appeared.

I could feel my heartbeats racing, after coming across this new signup page. I signed up using the bug…@google.com email and then it asked me to verify by entering the code.

Verifying The email address

I was waiting for the verification code in the conversation and then received the verification code in the mail.

After successfully signing up for the Google Account, I reopened the issue.

Nice catch!

Finally, at 9:50 PM that day, the most awaited email arrived $3133.70. I could not sleep the whole night.

Video PoC

Thanks to Alex Birsan this would not be possible without his write-up. I learned a lot from reading write-ups

Escalating SSRF in a Vulnerable Jira Instance to RCE via Docker Engine API

noreply@blogger.com (Unknown) — Wed, 28 Nov 2018 21:23:00 -0800

Originally posted by me on Reddit. This is just a repost of what I wrote there on /r/netsec, and formatting is a bit awkward. ~~Due to some glitch I found out it couldn't be published there.~~

Awhile back, I posted on Twitter about achieving Remote Code Execution in Jira instances deployed over Docker.

It's a common sight these days, to come across internal bug trackers of large companies who simply don't firewall their internal network. As a result, one can achieve varying impacts, but I believe, sky is the limit ;)

Orangetsai has previously demonstrated some exceptional cases of acheiveing RCE via SSRF based vulnerabilities, which further motivated me to research into this topic.

Upon delving deeper, I found out that, a huge number of Jira instances were exposed publically which itself is thought provoking and tempted me to look further into ways in which I could exploit it.

I was able to earn a couple bug bounties along the way on BugCrowd by successfully demonstrating XSS, with cookies scoped to parent domains in those cases allowing me to execute a full fledged ATO attack via Reflected XSS using SSRF in the Vulnerable Jira instance.
The next considerable impact was some critical information disclosure, which happened only at times, when you passed on a wrong or, malformed URL in your request and Jira gave you an interesting stack trace containing more internal information.
Only in two counts of cases could I leverage this to penetrate into the intranet of the concerned company (which was interesting alone) and find some internal vulnerable software. The impact kept on increasing at each step as I progressed further and this was no more a simple report which most security researchers are tempted to make viz. Reflected XSS, SSRF and Exposed Jira Panels. Hence, I got something more to put in my security report.
As I kept digging deeper, I came across a Jira instance which was deployed over Docker. Ask how? I put together a simple Python script that would keep hitting the consumerUri parameter with different payloads like [::1], localhost, and the likes, also with some deliberately filthy payloads just to exfiltrate some information. The endpoint is https://[Jira-server host.tld]/jira/plugins/servlet/oauth/users/icon-uri?consumerUri=

So, while monkey testing, and fuzzing I finally constructed this payload - https://[Jira-server-host.tld]/jira/plugins/servlet/oauth/users/icon-uri?consumerUri=http://[::1]:2375/containers/json

Bam! We got some sensitive docker credentials stored as environment variables through an unauthenticated request to the Docker Engine API via an SSRF vulnerability in that Jira instance and are now in a position to conclude we performed an RCE in an internal network where practically no XSS would hold that great an impact! This could be rare but a notable case.

Do you have some ideas on how to exploit this further? Do post your ideas on this!

What are Subdomain Takeovers, How to Test and Avoid them?

noreply@blogger.com (Unknown) — Tue, 21 Aug 2018 23:16:00 -0700

Introduction

Hostile Subdomain takeover forms a class of attacks which has appeared quite often in large organisations due to a large number of factors like human negligence and a huge overall attack surface. A similar sort of attack is stale DNS entries which often lead to the hijacking of the domain itself. This has already happened a number of times each in case of companies like Starbucks , Uber have already paid thousands of dollars for these security vulnerabilities reported by researchers. Uber actually had more than one subdomain takeovers in the past. This often leads to companies losing their trust over the users and various other implications, due to loss of millions of dollars when a successful subdomain takeover is maliciously executed and an attacker puts up a successful phishing campaign. In this article, I will discuss about practical cases, impact and mitigation of this attack and share useful tips to avoid such situations.

It's understandable though that for large organisations with a huge number of assets and servers DNS monitoring becomes too tedious, which can, of course, be automated with in-house solutions as well as paid ones and with a little care and effort be manually checked so that you don't leave stale DNS entries (CNAME records).

What are Subdomain takeovers?

Subdomain takeover vulnerabilities occur when a subdomain (subdomain.example.com) is pointing to a service (e.g. GitHub pages, Heroku, etc.) that has been removed or deleted. This allows an attacker to set up a page on the service that was being used and point their page to that subdomain. For example, if subdomain.example.com was pointing to a GitHub page and the user decided to delete their GitHub page, an attacker can now create a GitHub page, add a CNAME file containing subdomain.example.com, and claim subdomain.example.com.

Not only can this happen with your company's GitHub hosted pages but also with Amazon S3 buckets which are no longer in use but a subdomain is still pointing at it.

As an attacker one can thus make use of this stale DNS record to own the AWS S3 bucket or point one's own GitHub pages to your (sub)domain, which is no longer in use by your organisation and use it to target your innocent users into leaking their account details via XSS and phishing pages hosted on your companies' domains.

Further Impact

In many a case, an attacker can easily steal victim user's cookies via XSS if they are allowed on the subdomain, so that needs even little user interaction than usual phishing pages which are set up to steal user credentials.

Some Notable Cases of Subdomain takeovers

Given below are companies who have been victim to this attack in the past.

Slack - through podcasts.slack-core.com which was serving content via Feedpress
US Government - Via GitHub pages
GitLab
Uber - Leading to Account Takeover
Unbounced - Many different pages/domains belonging to different companies

And many more...

Mitigation

As an end user of a service - Going through your organisation's DNS records in a routine manner or while discontinuing or terminating a service, for example, a GitHub or an AWS S3 instance, safely removing it's DNS records.

As a service provider, by implementing stricter methods to prove (sub) domain ownership.

Testing for Subdomain Takeovers

Given below are some heuristic testing methodology to determine subdomain takeovers.

Heuristic Tests to determine if a sub-domain/domain can be taken over

Engine	Possible	Fingerprint	Reference
AWS/S3	Yes	`The specified bucket does not exist`
Bitbucket	Yes	`Repository not found`
Campaign Monitor	Yes	Support Page
Cargo Collective	Yes	`404 Not Found`	Cargo Support Page
Cloudfront	Yes	`Bad Request: ERROR: The request could not be satisfied`	https://blog.zsec.uk/subdomainhijack/
Desk	No
Fastly	Yes	`Fastly error: unknown domain:`
Feedpress	Yes	`The feed has not been found.`	https://hackerone.com/reports/195350
Freshdesk	No	Freshdesk Support Page
Ghost	Yes	`The thing you were looking for is no longer here, or never was`
Github	Yes	`There isn't a Github Pages site here.`	https://hackerone.com/reports/263902
Gitlab	No	https://hackerone.com/reports/312118
Google Cloud Storage	No
Help Juice	Yes	`We could not find what you're looking for.`	Help Juice Support Page
Help Scout	Yes	`No settings were found for this company:`	HelpScout Docs
Heroku	Yes	`No such app`
JetBrains	Yes	`is not a registered InCloud YouTrack`
Mashery	No	`Unrecognized domain`	https://hackerone.com/reports/275714
Microsoft Azure	Yes
Sendgrid	No
Shopify	Yes	`Sorry, this shop is currently unavailable.`
Squarespace	No
Statuspage	Yes	`You are being redirected`	https://hackerone.com/reports/49663
Surge.sh	Yes	`project not found`	https://surge.sh/help/adding-a-custom-domain
Tumblr	Yes	`Whatever you were looking for doesn't currently exist at this address`
Tilda	No	`Please renew your subscription`
Unbounce	Yes	`The requested URL was not found on this server.`	https://hackerone.com/reports/202767
UserVoice	Yes	`This UserVoice subdomain is currently available!`
Wordpress	Yes	`Do you want to register *.wordpress.com?`
WP Engine	No
Zendesk	Yes	`Help Center Closed`	Zendesk Support

Something that I missed? Feel free to add in comments and I will be adding them!