Interesting case,
I performed netinstall (without default config) on my device (Chateau LTE12) to latest ROS version (7.16) because I had some trouble doing it with regular upgrade procedure due to my fault (power failure while upgrade process was in progress).
After netinstall is done and rebooting I connected to ROS using Winbox and changed password but I was not unable to open Terminal (Terminal - not permitted (9)) because I wanted to apply my configuration from export. This raised suspicion and I looked into logs:
Device got hacked approx 1 minute after connected to internet, created backdoor System user and changed api port.
Since Chateau LTE12 is lte device it connects to internet immediately and in short period until password is set without default configuration device is vulnerable since I have public IP over lte, but I wonder how some scanner is such fast to detect unprotected device while password is not set…
I performed 2 netinstalls so far hoping I will be faster than scanner, but no luck, now I will go with some small configuration script which disables lte interface for avoiding internet connection until configuration is fully imported.
I done same thing in the past but never had such issues because device is unprotected in short period.
My IP is public but not static and I downloaded official ROS npks from MT site, it should not be compromised.
Curious because how fast it got hacked and hoping that ROS is not calling somwhere which triggers scanner and hacking over unprotected API.
Nah there are lots of hosts that are focused on scanning such things. I got caught by the same thing and ALSO with api but on a fresh CHR on VPS.
It’s actually your fault that you netinstall with WAN/modem link up, eject it until your config is reapplied and device is secure.
P.S.: still propose MT to disable api/rest stuff in defconf to prevent such things. Those API hacks seem to be common.
Yes sure Removed once and destroyed nanosim-to-microsim-to-sim adapter because it was very difficult to pull it out.
Netinstall was performed without config, no defconf or any config to avoid conflicts with exported config. Complex configs are not applicable for import automatically with netinstall, but I solved later with simple config script: /interface lte disable lte1.
The nano to micro is so thin on one side that it is rather easy to break, but having two adapters one inside the other increases this risk, as when you pull the external one the internal one may easily go out of the plane and actually be the cause of the jamming or at least contribute to it .
Only for the record, and as a side-side note, besides using the “right” adapter and not attempt to combine two into one, metal adapters (as opposed to plastic) do exist, they don’t cost (IMHO) excessively more and they are much more sturdy and the SIM fits in them more tightly.
Well after thinking why I was doing it like that in the past and not bothering much, it was because my MNO always assigned me WAN IP behind CGNAT over network provided APN which protects you from direct access from internet and in that short period until new password is set and firewall rules applied I wasn’t concerned, but it seems they changed that and I’m now getting assigned public IP for which I was needed to setup custom APN in the past. Now I definitely needs to be more careful when performing clean netinstall to apply config script for disabling lte interface after first boot.
Regarding damaged adapter I was wrong, it is only nano-to-micro adapter used since micro SIM slot is on device, adapter was damaged when I was last time pulling SIM out with tweezers since it is very thin plastic, no way to do it with fingers and push-to-eject never worked I’m sure, maybe was delivered damaged if LTE12 has such slot type.
Yep, but if the good Mikrotik guys (who have an established record for omitting even vital documentation and even when documenting it, doing it in the most minimal and succinct possible form) felt compelled to put this info in the manual, adding even a picture, it must mean that the issues with that type of slot/SIM holder was a known (and serious) one.
BTW I never understood why on relatively large devices nano or micro SIM are used, the mini/standard size is so much better.
There is another possibility (only for the record), there are extension cables that can be also converters for SIM sizes (though they are not cheap).
Example only, B3014A-N: https://www.amazon.com/ADT-Link-Converter-Adapter-Mobile-B3014A-N/dp/B0BXP2TLQB
I used different nano-SIMs from different providers with their adapters and never had an issue. I even once had a microSIM trimmed down with a cutter to the size of a nanoSIM (so I could put it into a smartphone), years later used it in an microSIM adapter again. No problem at all.
Isn’t it that cuttings for different SIM sizes are not through? So if one needs e.g. micro SIM, only outer piece of plastic has to be removed. The rest is still decently sturdy so that nano SIM doesn’t separate from micro SIM sized frame …
Removed once and destroyed nanosim-to-microsim-to-sim adapter because it was very difficult to pull it out.
:
