Was GL-iNet firmware compromised by the chinese national security law?

Listen, to reproduce it go to https://dl.gl-inet.com, or compile it from Github. Choose the latest firmware and log the connection data . Let the GL-iNet openwrt mod do the job. You will find that DNS-OverTLS is not properly working, the connection should break when the validation is invalid, it doesn't. In fact it does forward the DNS requests to a server in Beijing. With and without oVPN The logs on OpenWrt will show contradictions from when you for example check your dns via browser with a 3rd device connected to it.

Also thats not the point, I do not claim that OpenWrt does it, I'm saying the manufacturers software does and that people should just be more careful when I was. That is all.

Tested with Fedora, Rhel8, Ubuntu, Debian, MacOS

If you want to help read my posts more carefully, I had most of your points already clarified.
As said it could be a hack the GL-iNet team doesn't know of, they know about this thread at this point and I am awaiting a statement on the issue.
Their stuff is not cheap, if I would want to use random hardware from ZBT or alike I would and use stock OpenWRT, instead of paying a premium price. I am talking about flag-ship models for business use here. I have had many devices of them over the years. I have zero interest in harming them because that means my and my teams connections where compromised. Our company fled HK physically not too long before AppleDaily employees were denied to leave. I know what I am talking about.

2 Likes

I was expecting a bit more in-depth instructions than this, but ok. I'm not a super expert and I could use some pointers.
I have Linux on my PC, I can compile OpenWrt from source and can connect to stuff in SSH no problem, I just don't know the commands to do network troubleshooting and logging besides basic ping and such.

For now I'm just updating one of my Mangos https://www.gl-inet.com/products/gl-mt300n-v2/ to latest version from its own automated firmware updater, and exporting some openvpn configs from my Mullvad account so I can load them in this router.

I hope you can tell me just a little bit more and I can try this out on this device.

The first was a bit, but the second no it is not

In either case they won't tell. It's still a company that lives in another country, they don't fear international lawsuits, and if it is mandated by their government there is even less chance they talk about it.

Eh, please keep in mind that most people here are consumers, not businness customers, so if you talk of GL.Inet the main products they know (and love) are different.

Their mini routers have kind of cornered that niche of the market and can be quite cheap, (at least from my country I can get the Mango aka yellow one for like 25 euro and free shipping through Amazon, and the black one with external antennas for 35 euro), also the travel routers with socketed mini pcie modem are not very easy to find from other vendors.
I do like that support for their new devices in OpenWrt is quick and easy since either someone copies the source from their fork or their own engineers send PRs to add support.
They also have a nice firmware recovery with web interface so there is no need to set up tftp or connect serial or do any of that.

The only difference between the (newer) mini-routers I would grant is that the edge computing models have more power and have more space. I believe there is literally no other difference, but I can't prove that.

The thing is m8, no matter for whom these are, how expensive or cheap they are, f*cking around with DNS and VPN comnections is an absolute no no no-go. In any case.

And if they do not issue a statement it is because they do not want to, which would be even more worrying. They could send a partner of the company an particular american I know for example, to issue at least something. What is if you for example do homeoffice and use a mini-router to have your employer not having constant access to your lan? What is if this certain employer is any nation state?

Last point:
The link you send does not link to the latest stable (not snapshot) firmware, you can read that in their forums too.

:/edited because of typos, since all hardware and vps servers besides my phone are wiping right now

Hi, this is Alzhao from GL.iNet.

Thanks for raising this issue. Here is my reply.

From your screenshot we cannot identify the real problem. The DNS query may be from my PC to the router because you use DNS encryption. It also does not show if the query is successful or not.

I didn't get your report anywhere. Can you send again? To our support email or just to me via the forum.

The Chinese national security law does impact HK a lot. We have not yet affected and I don't see in which way we could be affected. The law does not require us to install backdoor in products. We need to obey the law where we sell the product to, not where we produce the products.

We have all our servers in the USA, Europe and Japan, not even in Hong Kong.

We do have a USA company and migrating some business there, especially for SAAS.

We are auditing our code from renowned information security companies. I just got a report weeks ago. We do have some issues to deal with, but not yet security risks. Especially we scanned the firmware and didn't find any info about the domain you provide.

9 Likes

Thank you for your answer, it's very much appreciated. I'll send it again via mail with proper logs, I didn't post them as stated above publicly for obv. reasons.

The thing that is of public interest is that if you look at the source code there is for some time now a new location: China. It's visable via any browers console, but not selectable. You also operate a .cn for some time now, why? https://www.gl-inet.cn/

How can DNS-OverTLS be activated and fail, giving no notice that it in fact failed and send the request to another server? That seems very odd. The connection should fail - period, otherwise it is nonsense to have this feature.

Why is the Cloud UUID saved at all times? This is at best a very minor comfort feature, at worst it's going to be exploited. A simple example is: What would be if you sell the device. The guy who buys it
can then not acess the Cloud-API directly, but its connected as if it were mine on some backend.
/edit
That's about it on that issue. I would wish it to be completely deleted on reset but well, if its not, its not. Forget about that - the DNS issue is my issue here

I don't suspect a backdoor directly, I worked in HK, we had servers there. I however think open-sourcing alone will not safe you. We used U.S providers operating in HK and there were always since ~end 2019 surveillance tools installed and compared to
anywhere else a rediculous amount of attacks by whomever were occuring.

Anyways, I'll go write you the mail with all proper information and hope we can figure it out.

@all Clarification following after figuring this out.

Waiting for your log.

Operating a cn domain does not mean anything. A lot of foreign companies operate cn domain. You can see that the cn content is very different from com content. Just two businesses.

If you enable DNS over TLS, if it fails you should get no dns response. I will check more info after I got your log.

Cloud UUID you mean device ID? Device is fixed. Wether a user can access a device or not is not from the ID, it is from the access control of the cloud. Only the own (who bind the device) has the right to access the info of the device. If you sell a device, the new user will need to bind the device to his own account.

To be clear. Device ID is the ID on the device. It is fixed. Cloud UUID is generated when you bind the device to your account. It is not fixed.

2 Likes

Maybe, so you operate a business in Mainland China which does something completly different and none of them are based on OpenWrt? Since the law states:
"

So this is bullshit?

Chinese Telecom Firms Can Exploit ‘Glaring Loophole’ to Enter US Networks: FCC Commissioner

By Ryan Bao April 1, 2021 Updated: April 1, 2021

A Commissioner of the Federal Communication Commission (FCC) is calling on the regulator to eliminate a “backdoor” that allows telecom firms with ties to the Chinese Communist Party (CCP) access into the U.S. network.

The FCC last year banned U.S. firms from tapping into an $8.3 billion government fund to purchase equipment from Chinese telecom firms Huaweiand ZTE after deeming them national security threats. But U.S. telecom carriers are still allowed to use private funds to purchase and use the same equipment, FCC Commissioner Brendan Carr said during a virtual panel event hosted by Washington-based think tank CSIS on March 30.

“Once we’ve determined that Huawei or any other gear poses an unacceptable national security risk, it makes no sense to allow that exact same equipment to get purchased and inserted in our communications network,” said Carr.

“This isn’t just a concern for the military,” he said. “Everything that we do in modern society now runs on interconnected networks, from banking to transportation, even our power grids…If these networks are threatened, everything that we have come to rely on is threatened.”

In 2012, the Congressional Permanent Select Committee on Intelligence issued a report stating that “Huawei and ZTE cannot be trusted to be free of foreign state influence and thus pose a security threat to the United States and to our systems.”

U.S. officials have also warned that Chinese telecom companies like Huawei and ZTE have close ties with the CCP. Under China’s national security law, companies in China are required to cooperate with the CCP’s intelligence agencies when asked, which could include granting authorities access to and control of their data.

Huawei also has several hundred CCP committees embedded in its corporate structure, Nury Turkel, commissioner of the U.S. Commission on International Religious Freedom, said at the same event. When needed, Huawei and ZTE will follow the Party’s leadership and policies, according to Turkel.

In addition, China’s telecom companies have played an important role in facilitating and carrying out the CCP’s oppressive policies on ethnic minorities, including Uyghur Muslims and Tibetans, Turkel said.

More than one million Uyghurs and other minority Muslims are detained in the Xinjiang region, where they are subjected to forced labor, torture, and indoctrination.

Huawei provides surveillance technology used in Xinjiang such as facial recognition, Turkel said. It has also provided technical support and training to Xinjiang’s Public Security Bureau, which has been put on the U.S. trade blacklist.

Carr also urged the United States to adopt more measures to ensure that electronic devices made with forced labor do not enter the U.S. market.

In May 2019, the Trump administration placed Huawei and its subsidiaries on a trade blacklist, which bars American companies from doing business with it without a license.

The FCC in December finalized rules requiring carriers with ZTE or Huawei equipment to “rip and replace” that equipment. It created a reimbursement program for that effort, and U.S. lawmakers in December approved $1.9 billion to fund the program.

Last month, the regulator designated five Chinese companies as posing a threat to national security: Huawei Technologies Co, ZTE Corp, Hytera Communications Corp, Hangzhou Hikvision Digital Technology Co, and Dahua Technology Co.

These are just some quotes. I know your devices are FCC approved, and indeed it makes a difference if you don't sell to the mainland. But I also had to understand this law and its so vaguely written that anything and nothing could be prosecuted under it. That's why I mentioned the .cn domain.

To sum it up: Ultimately everyone has to decide for themself who to trust, I think its better if we leave the topic as is and see if we can figure out the technical stuff and leave the law out of it. Just because we had major problems doesn't
mean you would have.If I can ensure that my DNS is not manipulated and nothing is transmitted via servers I do not want to, that would be okay.

Nice summary. I see there is a lot of problem need to solve. Hope the world can find a way.

8 Likes

As I said, the router with stock firmware has an integrated firmware update page, and I'm using that to upgrade the firmware. That link was just to show what hardware I have.

The thing is, if you want to be taken seriously, you have to provide decent instructions so that your claim can be validated by other people.

For now there is only a dude posting a screenshot of something in a forum, nobody has seen a log, nobody has seen full instructions to reproduce.

4 Likes

Can you please not do this flamewar bs on OpenWrt forums? We are not affiliated with nor sponsored by GL.inet, this is NOT the place to shout at them nor discuss their company's alleged affiliation with chinese government.
Please use their own forum to do that https://forum.gl-inet.com/
Even discussing faults in their firmware is technically offtopic since it's not official OpenWrt, but at least there is some interest for that so if you can keep it a civil discussion it is ok. I am still interested in testing my device, so if you can actually tell me the actual console commands you used to see that I will try here as well.
Notice that if you keep acting bad you can be banned (temporarily or permanently).

7 Likes

I haven't read all the replies so not sure if this is obsolete or not.
Why did not you stick to OpenWrt from OpenWrt? Why going for a fork?

Stock firmware being backdoored (on purpose or due to negligence) is not uncommon at all. Since Snowden's leaks we should all be used to that and consider it the norm, taking the enormous budgets of intelligence into account when estimating the advances of the decade which has passed since. If Cisco and Juniper got planted backdoors, why would you expect that to be different for other products on the market?
I mean, sure, it's bad and should be called out publicly, presenting clear evidence. And maybe this forum can be helpful for finding assistance for gathering that evidence. But please stick to technical facts which are reproducible (or whatever needs to be done in order to get there; I don't see legal debates and mere accusations of wrong-doing to lead us there)

The much more relevant question today has become if you are even able to fully replace that (potentially) backdoored stock firmware with anything else, and in case of GL-iNet the answer to that question is clearly: yes, you can easily replace everything.

4 Likes

"yes, you can easily replace everything."

Do we have clear knowledge about usage of "TrustZone" on the ARM offerings by GLiNet? Or any of the vendors?
Is there any switch chip, that has been (formally?) verified to be without (?unintended) (?undocumented) (?in-band) "debug" interfaces, that could influence packet routing decisions?

why a fork? what's wrong with the official OpenWrt?

What we are doing here (and I am very grateful for that) is opsec troubleshooting. What is happening here is the opposite of a flame-war. We are figuring out together if our opsec is compromised or not and doing this open in public. This could not be any better.

1 Like

Nothing is wrong with Stock-OpenWRT

Of course there can be silicon backdoors as well, but that should be blamed on the chip design or on TSMC or who ever physically made the chip then and not on GL-iNET which is just the downstream customer in that scenario.
In that sense, you can never be sure about that some magic data arriving on the WAN port wouldn't trigger things even worse than "just" ping-of-death. This obviously applies to the in-SoC circuits in charge of packet processing just as well as for external switch ICs.

But back to the software aspects you mentioned:
What ever is running in ARM TrustZone still has to be loaded there during boot (typically ARM Trusted Firmware A) and can be replaced unless secureboot is preventing you from changing it (and in case of GL-iNET only the top-edge Marvell AArch64 based devices even got a CPU capable of TrustZone, and there the boot ROM happily loads whatever it finds in the flash, so no problem to replace whatever you like to replace).

1 Like

I don't speak for GL-Inet, but from what I've seen there are multiple reasons:

  1. They wanted to use their own WebUI, so luci API-based WebUI packages are probably incompatible now, hence their own packages repository, hence fork.
  2. They are allowed/chose to use proprietary binaries for things like radio drivers or NAND flash, which OpenWrt doesn't do, hence their own fork.

They do contribute to support of their devices in the official OpenWrt a lot tho, to give you freedom to use their own firmware or official OpenWrt.

PS. This is not in any way to disprove your findings/theories, just addressing your specific question on forking.

1 Like

@something62256 Could you share your router's log to the community? (I'm not an expert, but maybe I learn something).

3 Likes