Hacker News new | past | comments | ask | show | jobs | submit login
UC Browser for Android, Desktop Exposes 500M Users to MiTM Attacks (bleepingcomputer.com)
120 points by cpeterso on March 28, 2019 | hide | past | favorite | 60 comments



FWIW UC Browser is prob the most popular web browser used on Android phones in China. Every device ive seen, or owned, has it pre-loaded or is top choice for getting loaded. I have also tried it out myself, but as other posters has written already, its awful.

Wondering out loud i would ask if the vulnerability to MiTM is actually required. From reports here in HN 2-3 years ago MiTM is basically what the GFW achieves, and it inserts its own headers to route away from intended(and blocked) servers and to benign local China servers(such as baidu). Perhaps this vulnerability exists in their need to be compliant to local Chinese law which basically prevents one bypassing/nullifying the GFW without permission?

This is an open and honest question, not an opinion. Hope someone can answer with facts. I lived in China past 12 years and have had enough hearsay, rumour, and opinion to last me multiple lifetimes :-)


> and it inserts its own headers to route away from intended(and blocked) servers and to benign local China servers(such as baidu)

I was never aware that GFW would route traffic to local China servers such as Baidu's, can you kindly provide some links?



If I'm reading them correctly, those two posts are the opposite of what the parent post tried to say.

Those DDoS were carried by directing traffic to GitHub while that traffic should go to Baidu.

Did I miss something?


Just had a quick Google and this company is owned by Alibaba: https://en.wikipedia.org/wiki/UC_Browser

Seems like they've already been in hot water for vulnerabilities in their browser: https://www.cbc.ca/news/canada/spy-agencies-target-mobile-ph...


What conclusion do you draw from that company being owned by Alibaba? I don't see the relevance of this.


https://www.uc.cn/

If you are meaning of the evidence of UC connected to Alibaba, I think this site is convincing enough.

[EDIT: Fix link]


You misunderstood me. I firmly believe UC is owned by Alibaba, but I insist that I don't understand why is that important.


Useful context for me as I haven't heard of the browser so no knowledge as to how they can have such a large userbase.

I don't think the intention was draw a correlation between Alibaba and security lapses.


Some of it may be inertia from early days of Android - for a long time I still had the Dolphin browser installed because for a time back in the Android 2.x days it was the best option around and IIRC included its own build of Chromium's rendering engine ("Dolphin Jetpack").

UC Browser is likely also available on devices not using Google Play where Chrome may not be an option.


Maybe it was because Alibaba operate a huge payments service network? This would be like PayPal making their own browser and having a load of vulnerabilities in it


I only posted it because it didn't mention Alibaba was the parent company in the article.

Maybe the article author would have had more luck getting a statement from Alibaba since it has a more significant international presence compared to UCWeb Inc.


I really hope this substantially reduces the number of users, or Google takes the app down completely. The browser is ridiculously terrible: both from the user and the developer point of view.

The browser constantly spams the phone with irrelevant, clickbait news articles/ads (and yet it's so popular). The developers (especially in India) cannot ignore the browser because of its large userbase, and then that's one more browser you have to look after.


> The browser constantly spams the phone with irrelevant, clickbait news articles/ads (and yet it's so popular).

Regular people don't stop using an app because it shows irrelevant articles, click baits. Facebook, YouTube trending are more "mainstream" examples of this.


> Android apps "distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play."

Obvious question: why did this get approved, and will Google amend their process to close this loophole?


Fwiw, Firefox Mobile lets you download add-ons and plugins, as well, that modify behaviour of the app. Not sure what justification UCWeb might have given here to Google, though, it is more likely that with certain apps, external install, command, and control is a valid and exceptional use-case.


Firefox extensions are just JS executed in a sandboxed runtime though..

By that logic you could argue webpage's JS are downloadable plugins that modify the behavior of the browser while it displays HTML content :)


In Firefox's case, the user willingly searchs for and installs add-ons, UC Browser did it on its own without informing the user


Presumably detection of all dynamic code loading is hard, especially since people also get pissed at google whenever there is a false positive and an app is removed for seemingly no reason.


Why would anyone use anything else than Chrome or Firefox on Android?

I wouldn't even trust Samsung.


I believe things might work pretty differently when it comes to China, which is the main demographic of this browser


And India, where it is heavily used. UC browser is the Yahoo of browsers. It bundles many app like features in the browsers and for a lot of people who aren't tech savvy, its they one node gateway to everything internet.


You mean you can't download Chrome?


People really use this browser?


It was the the largest browsers in Indonesia and India, at least in part because it's marketed as saving $$ on data by blocking calls to download ads and other scripts[1][2].

[1] https://www.scmp.com/tech/article/2130205/alibabas-uc-mobile... [2]https://marketingland.com/alibabas-uc-browser-beating-google...


While downloading gigabytes of own ads...


Sure! I have it on my Dell Venue Pro running Windows Phone 7. There's dozens of us.


Sure, lots of people install custom browsers because they don't like the standard ones, myself included. Fennec (Firefox but from f-droid) is super slow, Chrome is not an option for privacy, but Lightning[1] is fast and has most of the features I want so that's what I use at the moment. It might be vulnerable for something, but I'm taking my chances with some lesser-known browser versus having the pain of a super slow browser all the time. This is also one of the reasons I don't have a banking app installed or have ssh keys on my phone or something: my phone is just not as trusted as my laptop.

I remember that UC is one of the ones I looked at, probably even installed to try it out.

Edit: sibling comments mention popularity in India or Asia, but I'm from the Netherlands. My brother also has a habit of finding custom things (independently from me), sometimes quite questionable apps... it's not just asians that install non-google apps.

[1] https://f-droid.org/en/packages/acr.browser.lightning/


I think that I have read that it is really famous in India.


Yes. The userbase has grown bigger more recently due to the browser's free in-built VPN being used to circumvent the government's ban on ~800 porn sites[1].

[1] https://timesofindia.indiatimes.com/india/govt-plays-net-nan...


Well that's one way to grow...


According to Google Play [1] it has >500M installs and about 20M reviews.

[1] https://play.google.com/store/apps/details?id=com.UCMobile.i...


That only represents the data of Google Play. Considering China is one of the largest markets of UC, yet doesn't have access to Google Play, the actual number would be a lot more than that.

According to iResearch[1], it has 311m "monthly unique devices" in China in Feb 2019.

[1]. https://index.iresearch.com.cn/app/detail?id=12&Tid=73 (Chinese)


I see strange JS error reports from this browser sometimes


Yes. A company I worked for had a large Indian userbase who almost exclusively used it.


Yes, since new Android phones only have Chrome which is very heavy. UC Browser has a reputation of being lean, so it's widely used in poor countries.


It's popular in Asia.


"It’s impossible to be sure that cybercriminals will never get ahold of the browser developer’s servers or use the update feature to infect hundreds of millions of Android devices."

Apparently they didn't consider the same sentence would be just as valid if they replaced "browser developer" with Google...

This is an example of the authoritarian security sensationalism that's far too common today, and it only leads to the big companies like Google getting even more power over users. One of the most secure places is in an isolated prison cell.


If you continue reading you find the key difference to the comparison you just made:

> This unofficial update feature present in UC Browser can also be used by would-be attackers to perform man-in-the-middle attacks (MitM) attacks, potentially leading to remote code execution on compromised devices, because the app communicates with its servers using an unencrypted channel over HTTP.

It's a lot easier to use the update feature to infect millions of people when it's just using plain HTTP.


Then why didn't they just leave the first part of the sentence out completely? It would then be more factual and less scaremongering --- unless that's what they wanted, to push a "Google can do no wrong" agenda.

I have no problem with factual reporting of the risks; it's the scaremongering promotion of Google's walled-garden that irritates me the most.


If you care about security or privacy, it seems like you’d avoid Android.


But unless you can get Apple to make cheap devices for the masses (like Android One and Android Go) in developing countries, their high price point will push you towards giving up your privacy to have a smartphone and be reachable online.


Sure you can live without a smartphone, but if you are going to use a smartphone, it is the most secure and private option.


> using unprotected channels

It's not man in the middle. I have seen this mistake a lot lately. Man in the middle only involves encryption. Otherwise it is just injection or redirection. It is not a man in the middle attack merely because something happened in the middle of a transmission. There is always stuff that happens in the middle of transmission if you want to get technical about packet switching ARP resolution.

Specifically man in the middle deals with intercepting a certificate or key request in the middle of a transmission so that the encrypted tunnel is between one end point and the attacker. The attacker then establishes a second encrypted tunnel between themselves and the other end point.

Wikipedia page - https://en.wikipedia.org/wiki/Man-in-the-middle_attack

I am certain about this because I had to study it in order to pass the CISSP exam (first time go back when it was a 250 question paper test).


What are you talking about... It is man in the middle. This attack is a lot older than encryption, so if you think encryption is required then you've made a big mistake. It refers to literally a person intercepting your message before (or instead of) it reaching the intended audience.


Older than encryption? Encryption has existed since before the Roman empire.

> It refers to literally a person intercepting your message before (or instead of) it reaching the intended audience.

Every time somebody has pointed that out they have extracted that definition from the term opposed to referencing the term from a definition. It is similar to answering a question with only a restatement of the question.


I would be confident in saying MITM attacks have existed even longer than encryption.

- A dispatches messenger towards B.

- Bad actor intercepts messenger.

- Bad actor detains/kills messenger.

- Bad actor dresses up in messenger clothing.

- Bad actor delivers message to B as if they were the original messenger, having read/altered the message in the meantime.


MitM attacks have been around far longer than transport/network layer encryption has been commonly deployed, is what parent means. These days it's more commonly used to defeat encryption but there's plenty of attacks that don't really need it (e.g. ARP spoofing, etc etc)


I am not sure what you are trying to say. Yes, agreed, there are many forms of attack beyond MITM such as ARP spoofing.


> Man in the middle only involves encryption.

This doesn't feel right to me, so I would like to explore it if you are willing to help me understand. I've grabbed a couple of sources below which appear to contradict your assertion, but I'll admit I'm not expert on this topic so if I'm misunderstanding things, I'd appreciate being put right.

The Wikipedia article you linked to includes the following section:

> A notable non-cryptographic MITM attack was perpetrated by a Belkin wireless network router in 2003. Periodically, it would take over an HTTP connection being routed through it: this would fail to pass the traffic on to destination, but instead itself responded as the intended server. The reply it sent, in place of the web page the user had requested, was an advertisement for another Belkin product.

OWASP's definition uses plaintext HTTP as its primary example of a MITM attack:

https://www.owasp.org/index.php/Man-in-the-middle_attack

> For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.

> The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based


Yes, technically because it's conducted by someone in the middle of the transport path, you can call it man in the middle. The problem is that if you call all attacks that, what do you call the attack where asymmetric key exchange is being replicated by some attacker in the middle?

Also, it's possible to pull this particular attack off without being in the "middle",. For example, by using DNS cache poisoning or arp spoofing


> The problem is that if you call all attacks that, what do you call the attack where asymmetric key exchange is being replicated by some attacker in the middle?

You use a more exact term. I don't see the problem.


I think you are missing the prior commentor's point. MITM already has a specific definition. It isn't as broad as you are attempting to redefine it.

This concept is commonly understood by security people and commonly confused by software developers. I suspect the failure is that for software developers all parts of a network are in the middle between their application and their end user, so anything in that nebulous space corresponds with the words comprising MITM. That line of thinking is reductio ad nausium.


The OWASP definition is correct. The gist of a MITM is that each end of the transmission trusts that the malicious actor in the middle is the target destination. When this occurs at the application layer it is almost universally centered on encryption. Keep in mind that in TCP/OSI terms the web is an application riding the internet. Without encryption how do you trust that the destination is who they claim to be?

MITM can occur on routers if the router is compromised by someone malicious or if it lacks integrity from the service provider. Routers are layer 3 devices that connect different networks. If a router is compromised so that traffic is sent to a different network with spoofed domains and content. One resolution is that form of attack is IPSEC. IPSEC is not often used across the public internet, because much of the public internet is still IPv4 and still reliant on NAT and PAT to compensate for a shortage of IP addresses.

Even more rare than that is certificate spoofing. This is hard to execute, which is why public certificates are usually good for as long as a year, but it does occasionally happen. This is why there are certificate revocation procedures.


> The OWASP definition is correct.

Okay. Your definition, with its additional encryption requirement, is at odds with the OWASP definition.

> Without encryption how do you trust that the destination is who they claim to be?

Signing? Or just ignorance? I agree that "trust" is a component, but it doesn't have to make sense. I can still fool you and the server to which you're connecting into thinking I'm the other party.


> Okay. Your definition

Not really. I did expound on this in the very comment you replied to.

> I agree that "trust" is a component, but it doesn't have to make sense.

Perhaps that is true if you are a hobbyist commenting on the internet. It does have to make sense in security management, though. The definitions of the terms are well understood in business and there are liabilities when associated terms are violated. That is why there are security certifications that are valued and recognized by the software industry, so that the people who do this for a living having a common shared understanding of the risks and penalties.


First, thanks for engaging! I appreciate getting corrected on this.

> Not really. I did expound on this in the very comment you replied to.

I agree with your expounding. Perhaps I'm not seeing where you addressed my concern, but these statements:

1. "Man in the middle only involves encryption."

2. "The OWASP definition is correct."

seem to be at odds, given that (3.) the OWASP does not exclude attacks on unencrypted channels (per their MiTM page). One of your statements (1 or 2) must be wrong, or my understanding of the OWASP definition (3) is wrong.

I'm not sure what to make of your response to my "trust" comment (though I agree with everything you said, it seems to be in a different context from the question). We're probably speaking past each other. Let me try to tease out the disagreement.

> The gist of a MITM is that each end of the transmission trusts that the malicious actor in the middle is the target destination. When this occurs at the application layer it is almost universally centered on encryption. Keep in mind that in TCP/OSI terms the web is an application riding the internet. Without encryption how do you trust that the destination is who they claim to be?

So does your definition of "trust" here _require_ encryption? Is encryption _explicitly_ required in a MiTM attack, or is it only required for "trust" (which I agree is necessary).


How is anything online trusted? The most common way to establish trust, for anything, is through hashing. Online locations apply hashing via certificates issued by a trusted certificate authority. Those certificates can be spoofed just as a destination domain can be spoofed. The strength of security is that it takes extra work to spoof two unrelated things and that the issuing CA is trusted by other CAs and applications. On the web exposure to risk is limited by usually only applying those certificates to the key exchange of TLS. These certificates can be used for more though, like digital signatures on documents.


Not going to down-vote just because you’re wrong, since you bring up a cogent argument. But it’s still wrong nevertheless. I’ve skimmed the linked Wikipedia article. Could you quote from that article that MITM requires intercepting a certificate or key request?


> As an attack that aims at circumventing mutual authentication, or lack thereof, an MITM attack can succeed only when the attacker can impersonate each endpoint to their satisfaction

According to the Wikipedia definition a MITM attack must impersonate the end point to each end point. Altering the integrity of a communication or reading the contents thereof does not meet that definition. Also, every part of the Defense and Detection section of the article is specifically about encryption, particularly PKI keys and CA issued certificates.

You never said how I am wrong.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: