Nice work! 🎉🎉
Maybe can go find if they have a bug bounty program and report it.

That's how cheap IoT device works in general. Keep pumping out new model and sell them while using the reference design is the same.

Have you identified where is the vulnerability? Is it in the webserver? Or within the web-app? Or somewhere else?

EDIT:
I suspect they have a default key for the token and manufacturer is expected to change it but didn't.
Maybe you look for it and change it for your PON stick.
Most developers are not aware of such things. The most recent one being ASP.NET:
https://www.microsoft.com/en-us/security/bl...t-machine-keys/

It is indeed a serious vulnerability. However, as you mention, ISP tend to cheap out with their equipments, and never bother to issue patch to their equipments. I firmly believe that ONR being supplied to end-users to further cut cost with supplying standalone units to end-users. Hence combo unit proven cheapest for them to save cost further. Not to mention poorly developed firmware.

I toyed with the Black D-Link DPN-3060, Skyworth (white), not impressed with the firmware. Not yet toy with Fiberhome and ZTE ONR.

An absolute time bomb if end user compromised, not to mention businesses that using stock ONR as their gateway to the internet.

If you encounter the following problems:
a. When PPPoE dial-up, the MTU will auto adjust from 1492 to 1480 after connected 3 seconds.
b.If you enable IPv6 you will get many warnings in the log similar to:
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:101
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:102
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:103
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:104
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:105
invalid mtu 1492 on pppoe-out1 from fe80::200:5eff:fe00:106

Then congratulations, this is because your ISP uses Huawei's Broadband Remote Access Server and you are a victim of Huawei equipment.
Affected peer equipment models: ME60, NE40, NE9000, VNE9000, etc.

Here is an explanation of the this issue:
a.Huawei has launched the vBRAS structure, which splits the traditional BRAS into the User Plane and the Control Plane.
b.The Control Plane name is VNE9000, which is an X86 virtual machine deployed on the ISP's cloud.
c.The User Plane consists of an X86 virtual machine or or an ARM physical machine or a traditional BRAS (such as ME60, NE40, etc.), there are deployed at sites near subscribers.
d.The User Plane is incorporated into the control plane and managed using OpenFlow.
e.The User Plane and Control Plane are connected using VXLAN, they may be hundreds of kilometers apart, with a delay of about 2 to 8 ms
f.Subscriber's PPPoE dial-up request will first reach the User Plane. If it is a packet of 0x8863 or 0x8864, the subscriber information will be injected and forwarded to the Control Plane through VXLAN. Then, after the Control Plane completes PPP authentication, it will send the flow table to the User Plane through OpenFlow. If it's a normal PPPoE Session packet, it will be fast forward on the user plane.
g.RouterOS and most network equipment implement PPPoE in compliance with RFC4638.
h.Therefore, when the RouterOS's PPPoE Client dial-up, if you set the MTU>1488, it will send an Echo Request packet with a length equal to the MTU to the other end during the LCP negotiation phase.
i.Yes, you have found the issue now. The size of your Echo Request packet has exceeded the VXLAN MTU between the User Plane and the Control Plane. At this time, the Control Plane will never receive your Echo Request or reply to your Echo Request. Therefore, when your PPPoE Client fails to get an Echo Reply after three attempts, it adjusts its MTU to 1480 in disappointment.

Are u using unifi biz bro?

I little bit curious why ur JB friend dialed to TM Ipoh juniper imse01.tsk_tp.re0 where the pppoe client supposed to dial imse01.jhb_*.re0 .. I never doubt if Cameron Highland users dialed to imse01.tsk_tp.re0 🤔

Seem physical imse01.mc_rsh-re0 now upgraded to virual ibse03.rsh ..  u dialed to malacca before. As for ur friend, actuality somewhere at perak.

tsk_tg = tasek_taiping
mc_rsh = malacca_rasah

There is another problem after they allow MTU 1500.
In IPv6, the BNG will send ICMPv6 Packet Too Big even if the MRU is 1500 and big enough to receive it.
Using IPv4 doesn't face this problem. My guess is they put in this broken workaround because some of their supplied router eats ICMPv6 packet in the name of firewalling.

There are other minor issue with their BNG the last time I test them, such as the weird reuse of magic number.
I also don't quite understand why their L2MTU cannot be increased, considering TM claim's all their MPLS circuit runs 9k MTU worldwide in their marketing material.
Maybe their marketing team lied.

The upstream speed not as suscribed although config correctly by GEM/OMCC. For this case need to manually config in the OLT itself. Below is the flow how GPON upstream normally work.

ONU Activation:
When an ONU is activated on a GPON network, the OLT sends PLOAM messages to the ONU to establish communication and discover the available T-CONTs. 

Bandwidth Allocation:
Using PLOAM messages, the OLT assigns specific Alloc-IDs to different T-CONTs within the ONU, thereby defining which T-CONT will be used to carry specific user traffic. 

Traffic Management:
Once the Alloc-IDs are assigned, the ONU sends upstream traffic based on the allocated bandwidth for each T-CONT, ensuring efficient utilization of the shared fiber. 

Conclusion is suspecting Asus router firmware bug?? Need to check with Asus.

In conclusion, consider seriously before throwing money into Mikrotik. People already doing networking professionally or have passion will enjoy it.

With a managed switch, one has to configure the switch ? Hmmm me not technical to do it. Assuming the issue is fixed with a L2 managed switch, the issue was original caused by tm or my Asus router?

You mentioned about TM made changes in Flow Control And QoS on their end, do you have any specific case logged with TM where I can use that as reference for checking with them ? It’s so hard communicating with their back end technical where just don’t answer any of my question. They only deal with their own technician.

For archer ge800, it’s one of the model I planning to replace my Asus if all else fail, with this model and existing dlink as modem in bridge mode, you you think the upload issue will be resolved?
Really  appreciate your help on this. Thank you so much.

Anime4000 the use of IoT item in router & IoT cloud. The same concept used by ip cctv which can remotely view using smartphone.

So let me guess, TM going to ignore this issue? Is there any official or insider confirmation that they were aware of this vulnerability and working on patches? Does this only affects the Ultra Combo ONRs or the regular ONR as well (+ Fiberhome and ZTE)? Did they replicate the vulnerability at their R&D side?

Thanks for the detailed explanation. I did went through the blog of the owner. He perfectly replicate and explain the vulnerability of using unpatched ISP equipment's. Hence Maxis is the next best option if new users wants to subscribe internet access due to maxis is still giving the standalone units. I guess they are using Skyworth if not my mistaken.

I get your logic there. Do you think they will use the older configurations back on, since ONR is not a permanent solution, especially for businesses. I mean, we are talking about an unpatched vulnerabilities. There are a few engines that can provide details about the ports, and some still using default login credentials. I've seen my clients using ONR for their businesses, only to be secured by a dedicated firewall.
Assuming maxis user who sub to Maxis's 2Gbps plan, and after 2 years, the user wants to shift to Unifi. This means, without the OMCI push for LAN 1 and 2 for the ONU, the ONU will be forcefully replaced by ONR, right?

Gotcha. Guess maxis will be my next option. I am not convinced of how TM and their engineers don't follow up the reported CVEs and issue a proper patch remotely or downloadable firmware from user account dashboard.

how about GPON STICK Mikrotik LAN SpeedTest please without 10G Managed Switch
GPON STICK > Mikrotik > ROG Crosshair VIII Hero (WI-FI) [Realtek 2.5G]

let do test show me