Malware found preinstalled in classic push-button phones sold in Russia
therecord.media
therecord.media
In France, some cheap SIM cards charge per mb and per SMS until you register a plan. So I carefully disabled mobile data, avoided SMS, loaded 10 EUR of credit over wifi, which 'activated' the phone on the network, but when I went to sign up for the 10 EUR plan, I found I only had 9,95 EUR left.
As soon as credit was loaded, my iPhone sent an SMS ping to an Apple shortcode to tell iMessage my new number. The sending and record of this SMS was completely hidden from the user on the phone. Cue some he-said she-said with the carrier about whether I did or didn't send an SMS. Most mobile providers zero-rate shortcodes to Apple and hide it on their billing system too, but not Lebara.
So I had to add 5 EUR more of credit just to buy the 10 EUR package for the month.
I'm only guessing at the SMS' contents. I can't see the message my own damn phone sent.
https://en.wikipedia.org/wiki/MSISDN
Now, could someone somehow change this and do something nefarious because it'll mismatch with what the network things? Maybe. But what's stopping someone from iMessage takeover by messing with the SIM and sending a spoofed message to the shortcode?
But someone could send any info to the shortcode indirectly. Not sure how apple encodes the info its sending, or if it's just sending a signature that authenticates the message.
But the phone could also wait until wifi is lost to send its 'ping' to Apple for the new number to associate with the phone because it could only be for SMS backup message reception purposes I would think. This would also permit it to backoff sending SMS to the old number if out of range of wifi range. (Is there a DoS case against this? I don't know).
Of course the iMessage service needs to know your phone number before marking your number as iMessage-capable and routing messages directed at your phone number to you.
I'm reading that article as the SIM only has an IMSI, and the MSISDN routing is all on the provider end, the SIM doesn't know or care.
This has also been my experience when traveling and using local SIM cards. My phone has a space to show your own phone number, and a rare few SIM cards have this pre-filled out but usually you have to enter your own phone number yourself, the phone doesn't know.
It also gives you the option to cancel before it sends the SMS.
https://apple.stackexchange.com/questions/404573/why-do-imes...
https://discussions.apple.com/thread/251223977
https://discussions.apple.com/thread/250349230?answerId=2506... (2019 - iphone sending 16 int'l SMS/day trying to activate, $5/day in pakistan can be a lot)
Maybe they've ignored the popup, but the first and third examples definitely doesn't sound like that.
My guess is that Apple keeps a list of carriers that agreed to zero-rate these and keeps an on-phone index to determine whether to pop up that message, but what Apple thinks carriers do and what carriers actually do are 2 different things.
Lebara is an MVNO so it could also be an issue where the phone is applying the rules for the underlying network rather than the MVNO.
MVNOs in the country I live in have a lot of issues with iPhones applying the mainline network settings to the point where you had to manually install a specific provisioning profile just to get the APN settings right.
Apple inc. should still ask for my consent before they spend my money. Just because they run some 'exclusive' black box messaging service doesn't mean they can pull shit like this.
When i spend bank money i have to enter my pin and authenticate. For my phone carrier money/credit i get no formal bank transaction screen like i do with Apple pay or similar. It's just a popup similar to those never-ending iOS update popups.
Why? Both are money. Why is spending bank money much more respected than spending phone carrier money?
Exploitation by telecoms has been normalized, so we still accept things like this happening (like OP having to buy €5 extra credit for being 5 cents 'short'). In Europe there are many more protections now, e.g. they also abolished extortionate roaming charges throughout Europe, but that took a very long time and we still have a long way to go.
I wish we treated spectrum licenses like driver’s licenses: a privilege that can be taken away. And no, no refunds for the time and money you put into getting it.
At least in this Russian case, you’ll see some indication on your bill. That’s not always the case with Apple’s SMSs.
Especially if I had to pay for each tcp header.
Yes. https://en.wikipedia.org/wiki/Signaling_(telecommunications)
> Apple and the carrier are also "other people."
Don’t be silly.
> Whose phone is it anyway?
Whoever bought the phone.
> Any action taken by a device one controls should be made transparent and auditable by the device's owner.
Ok, this is a moral and ideological position in favor of all designs of all silicon, all circuitry, and and all software being entirely open source.
It’s valid to argue that we should live in such a world, but it’s not an argument that Apple using SMS for signaling is equivalent to malware. Sorry.
> They are meant to be tools,
They are tools.
> not undomesticated semi-wild animals with a will and mind of their own.
Weird analogy to use to describe signaling traffic.
You could root it, and that would actually give you full control to delete/install/modify whatever you want.
I think the real lesson here is that if you do not have full control over a device, it is not truly yours and may disobey you.
It's like when people state that online voting should be safe because online banking is safe. I'm pretty sure if a nation state really wanted to steal a few grand from your (individual) bank account, they'd be able to do it. But it'd probably cost them more money/power in doing so then it's worth it.
They all could do it, but are you aware of any manufacturer-installed malware or rootkits on a device that have? They don't steal your bank account info or impersonate you ever as far as I know, they make money off you in the same way every other company does.
If we can't show any instances, then it becomes difficult to find this materially worse than what other tech companies do. It becomes more like embarrassment from being owned by a obscure foreign company rather than a famous American one.
That account name is apt. Everybody -could- do it. Even your spouse, your best friend, your parents. They could all steal your shit. But for sanity’s sake a balance has to be struck between trust and paranoia.
These oversized American corporations are practically untouchable to the majority of people. They'll pay their laughable fines, pinky promises to better self-regulate for real this time, and move on. Leaving you in the dirt.
You can believe in that, and trust them, but you cannot prove that, unless you have access to the source of everything installed by Google/Apple, and source of third party apps, favored by Google/Apple. But, even if you're working for a government agency and have access to sources, it's still a monumental task to do, because of the volume of the sources. It's why we, Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source.
Nah, most Linux owners didn't care and the fact that the most distribution voted with their feet to switch should say enough. Also, full init script were not trivial.
At this point, every distribution disables that setting, but it shows that systemd's developers cannot be trusted to make reasonable defaults, and must be double-checked to avoid blatant foolishness.
And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence.
The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best.
Discussion at the time: https://news.ycombinator.com/item?id=11797075 Continued defense of the decision as January 2019: https://news.ycombinator.com/item?id=19023232
I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html)
Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard.
The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback.
With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.
I can't agree, IMO processes left over after a network connection terminating could be considered a security hole. That's up to the sysadmin how to set it up. I certainly don't suggest getting into the habit of launching long running tasks in an ssh session, a remote sysadmin could already very easily end your processes if they find you AFK launching things on a sensitive machine. Systemd just gives some standard tools to do that.
>Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. [...] The short-term drawback is that programs that correctly request to be long-lived are killed.
This is incorrect, traditionally SIGHUP only means that the controlling terminal was disconnected. What you are describing is only correct for a single login shell with no sub-reapers, on a modern setup there are other things besides logging out that will send SIGHUP, such as for example if you run your program in an xterm and then close the window, or if you are operating within a sub-shell, etc. SIGHUP provides no way to differentiate those conditions, plus some programs will overload SIGHUP to be a "reload config" command, etc. SIGHUP is just not a reliable way to do it, I would not describe that as correctly requesting to be long-lived. SIGKILL is unfortunately the only method the kernel provides to do a reliable cleanup.
>The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits.
AFAIK there is no portable or simple way to do this, please enlighten me if I am missing something. Using daemon(3) and SIGHUP is not adequate here for reasons described above. Of course other init systems are free to create their own simplified implementation of systemd scopes, while skipping the Linux specific directives if they want. So it's not clear what your actual complaint is and what you mean the drawbacks are. Do they need help doing this? If so I would be happy to advise.
>in both cases, programs can persist, so there isn't a security benefit.
This is also incorrect, in the case of systemd scopes, you can further restrict the ability to create them with polkit or SELinux or similar. So you could make it so only tmux is allowed to start one for example. That would be one of the big benefits of having a real API for this versus just sending a signal and hoping the program is well behaved.
>The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks.
I don't think that is warranted, systemd developers can decide for themselves the trade offs of their program. The vitriol is not needed and is in fact likely to weaken the argument. In any case there are several other inits to choose from with their own set of strengths and drawbacks, I suggest focusing on what choices you have rather than agonizing over the small decisions of just one of them.
...
Last time somebody tried to sue Google for billing them for some random game, it didn't work out that well
unfortunately, thats a strawman position.
Not sure I understand why you would cry about that, systemd is actually not a very complex project if you're used to low level C daemons. The most complicated part is the d-bus portions, but those are mostly a lot of boilerplate, and you should be understanding it anyway if you use a modern system with d-bus. Trivial initd and trivial shell scripts are also lacking in quite a bit of functionality compared to systemd, at least in my experience those would tend to grow until they became brittle and unmaintanable.
a) only turns its spotlight on companies above a certain size/visibility,
b) can be defeated with a large enough marketing/lobbying spend, and
c) can be waited out by companies with other lines of business that bring in profits, and
d) can be combated with cycles of withdrawing, quietly reintroducing, then withdrawing again, and reintroducing again until
d1.) media outlets get bored with it, or
d2.) all other companies in the same line start to do the same thing, a traditional way of price-fixing. Once this happens, the only way you'll be stopped is with legislation, because e.g. every TV has banner ad pop-ups from the manufacturer now.
AFAIK, Samsung and cheap Chinese brands (Vizio, TCL, and similar) do this.
Months ago I was between buying a LG or a Sony because they don't have bad reputation around this, and the LG I finally bought haven't any ad. Also, cookies, extra internet stuff, and the Alexa service can be deactivated separately without affecting apps like Netflix
Got a new phone at some point and tried it again, and they were on some real shit by then. All the default built-in programs for like, /music playing/ would force you through a Xiaomi Cloud sign up process just to play music /already on your phone/.
Granted, Google is now on the same shit; I found with my latest android they've removed all the basic apps for file browsing, music playing, and the like. Now only "Google Play" versions remain, that of course require a Google account.
I feel like the camera and calculator are the only non-play-required default apps left, but I won't be surprised if I find one day that the camera is somehow integrated into Google Photos, which will of course not open until you sign in.
That makes it doubly shit that even premium products - TV's, laptops, etc - that aren't cheap or budget can come with ads, tracking and shitware pre-installed.
I'm thankful that my TV showed me separate licenses for things like advertising, tracking and voice control and wasn't difficult or annoying when I did not accept them.
For doing the crimes, use a desktop PC with a TailsOS flash drive and communicate with XMPP with OTR preferably with Intel Management Engine neutered and removed. Do Not use a smartphone or dumbphone for criminal dealings.
Think political dissidents and groups that support them like citizenlab.org, people working on classified projects - or with geopolitcally important trade secrets (which is actually a pretty broad range), members of the military in times of war - or when working with classified information/going to classified locations, people susceptible to being blackmailed with things like nudes of themselves, and so on and so forth.
Why, so that it can send the accumulated data the next time you're using the phone?
This solution is of course a nonsolution. It vaguely acknowledges the problem of NSA spying yet does not offer a meaningful collective response to counter it (e.g. pushing for open source movement and technology embedded in an anti-capitalist framework/system).
> Here it was one to one, on a simple dialer with a flashlight from Fly, Bata bought it, because he liked the big screen and big buttons, what he needed, he can't even write SMS, only calls, so the tariff is without the Internet. And it began, once every two or three days, Internet access (usually at night) for 15-20kb, and the operator rounds up to a megabyte. Just like you, I turned off the data transfer in the phone, deleted the dots, everything was useless.
https://pikabu.ru/story/troyanyi_i_byekdoryi_v_knopochnyikh_...
The (a?) Russian seller has now recalled the phone:
> DNS announces a recall campaign for two models of Dexp cell phones:
> DEXP B281 2.8 "GSM / 2SIM / 240x320 / 0.3MP / MicroSD / BT / FM / 1000mAh > DEXP SD2810 2.8" GSM / 2SIM / 240x320 / 0.3MP / MicroSD / BT / FM / 1800mAh
> due to possible manufacturing defect.
https://www.dns-shop.ru/news/374ef223-0bc4-11ec-a2b1-00155db...
If one thought of espionage...
> Also intercepts SMS confirmation messages and replies on behalf of the user
> All the remote servers that received this activity were located in China
I also want to mention that "Russian hacker groups don't do cybercrime at home, and the state lets them do it abroad" meme, which half of HN seems to sincerely believe, is extremely misguided, and just sounds bizarre to anyone who follows the topic. There is a continuum of loosely related Russian-speaking criminals in Russia, Ukraine, Belarus, Kazakhstan, and Baltic States (mostly Lithuanian criminals who traditionally work as the EU bridge for others), and it's always hard to tell who located where. Some of them have some ties with the Russian state (regardless of the country of origin), most don't. Domestic cybercrime is rampant in Russia, often involves big names (such as top 3 mobile operators in Russia) and the mere notion it's controlled in some way is ridiculous. The only issue is there's not much money to steal, so they turn to EU and US targets.
In such companies, you typically leave any electronic devices on you (including watches) at the gate, from clocking in to clocking out. Nobody would care if your phone is dumb, it's still breaking the rule.
I agree that this event is unlikely to be espionage, but someone important might buy a cheap dumb burner phone. I wouldn't put it past an intelligence agency to wholesale compromise cheap dumb phones for that reason.
could you share any source for this?
The real criminal here is Russia's big three (I would say, excluding MTS but including a new hot contender Tele2) who repeatedly rob vulnerable and elderly people via "paid content" schemas which have zero usefulness outside of scam.
sure. It is different endeavor/specialization though. Stealing just several thousands CC from Sberbank leads to Sberbank security paying you visit at home late night with you completely voluntarily signing confession and a letter of apology well before the dawn.
As a burner phone maybe?
They are a small chain from Vladivostok
This could end up costing you an absolute fortune in Canada if you use data without a mobile plan.
> The phone sends an SMS with the phone IMEI and IMSI codes to phone numbers hardcoded in the firmware.
This could be fun.
[1] 3GPP TS 23.038, Clause 4
Basically if you're fine with dangerous windows-only no-VM Miracle Box, it supports all the devices.
The intent was to use a single word to convey most of a complex intent, without diluting the message trying to express nuance that is better left to the reader to evaluate.