UC Browser for Android, Desktop Exposes 500M Users to MiTM Attacks
bleepingcomputer.com
bleepingcomputer.com
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 :-)
I was never aware that GFW would route traffic to local China servers such as Baidu's, can you kindly provide some links?
Those DDoS were carried by directing traffic to GitHub while that traffic should go to Baidu.
Did I miss something?
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...
If you are meaning of the evidence of UC connected to Alibaba, I think this site is convincing enough.
[EDIT: Fix link]
I don't think the intention was draw a correlation between Alibaba and security lapses.
UC Browser is likely also available on devices not using Google Play where Chrome may not be an option.
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.
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.
Regular people don't stop using an app because it shows irrelevant articles, click baits. Facebook, YouTube trending are more "mainstream" examples of this.
Obvious question: why did this get approved, and will Google amend their process to close this loophole?
By that logic you could argue webpage's JS are downloadable plugins that modify the behavior of the browser while it displays HTML content :)
I wouldn't even trust Samsung.
[1] https://play.google.com/store/apps/details?id=com.UCMobile.i...
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)
[1] https://timesofindia.indiatimes.com/india/govt-plays-net-nan...
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://www.scmp.com/tech/article/2130205/alibabas-uc-mobile... [2]https://marketingland.com/alibabas-uc-browser-beating-google...
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.
> 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.
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.
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).
> 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.
- 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.
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.
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
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
You use a more exact term. I don't see the problem.
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.
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.
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.
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.
> 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).