xHelper Malware for Android

xHelper is not interesting because of its infection mechanism; the user has to side-load an app onto his phone. It’s not interesting because of its payload; it seems to do nothing more than show unwanted ads. it’s interesting because of its persistence:

Furthermore, even if users spot the xHelper service in the Android operating system’s Apps section, removing it doesn’t work, as the trojan reinstalls itself every time, even after users perform a factory reset of the entire device.

How xHelper survives factory resets is still a mystery; however, both Malwarebytes and Symantec said xHelper doesn’t tamper with system services system apps. In addition, Symantec also said that it was “unlikely that Xhelper comes preinstalled on devices.”

In some cases, users said that even when they removed the xHelper service and then disabled the “Install apps from unknown sources” option, the setting kept turning itself back on, and the device was reinfected in a matter of minutes after being cleaned.

From Symantec:

We first began seeing Xhelper apps in March 2019. Back then, the malware’s code was relatively simple, and its main function was visiting advertisement pages for monetization purposes. The code has changed over time. Initially, the malware’s ability to connect to a C&C server was written directly into the malware itself, but later this functionality was moved to an encrypted payload, in an attempt to evade signature detection. Some older variants included empty classes that were not implemented at the time, but the functionality is now fully enabled. As described previously, Xhelper’s functionality has expanded drastically in recent times.

We strongly believe that the malware’s source code is still a work in progress.

It’s a weird piece of malware. That level of persistence speaks to a nation-state actor. The continuous evolution of the malware implies an organized actor. But sending unwanted ads is far too noisy for any serious use. And the infection mechanism is pretty random. I just don’t know.

Tags: , , , , ,

Posted on November 8, 2019 at 6:10 AM • 84 Comments

Comments

Alejandro • November 8, 2019 6:36 AM

Maybe it’s just beta test tweaking to make sure it works until the BIG DAY arrives to …I don’t know…brick, everyone?

A Nony • November 8, 2019 6:41 AM

Or this is a modern-day example of robinhood and friartuck, and that was written by folks a Motorola 30 years ago.

Clive Robinson • November 8, 2019 7:03 AM

@ Bruce, ALL,

I just don’t know.

Such is the joy or not of cyber-attribution.

I’m glad you and others are now feeling it’s safe to say.

It’s a sign the industry is starting to become more mature in it’s behaviours.

K.S. • November 8, 2019 8:10 AM

@Victor Wagner

If we are doing paranoid conspiracies, a much better story would be if Apple is behind this malware to show how insecure the entire Android platform is. Such persistence should not be possible in a well-functioning OS.

H. E. • November 8, 2019 9:26 AM

So a somewhat smart random nobody is totally out of the question? This looks like someone got lucky and now (ab)uses one unique bit likely found by themselves or heard in some murky backwaterchannel. Probably just wrote a line in to unsecured factory reset code. Or another well known but hard to spot vulnerability.

But google does offer brickloads of money for persistence exploits, ought to be known by those holding them, likely they figure to make more money selling ads and owning devices. Google doesn’t earn much off of old devices, especially those only sideloading apps, bypassing playstore and so forth.

Plenty incentive to run something this nasty to justify making sideloading next to impossible 2020. Didn’t google sell ads?

Michael • November 8, 2019 11:18 AM

I read through some of the details online, particularly one Reddit thread provided some insights, and I have a hypothesis. The xHelper malware’s persistence seems to only affect certain devices which suggests this malware is not using a general Android exploit but rather some other exploit that only works on specific devices. From the Reddit thread, the HTC One X is definitely affected by the persistence while the Galaxy Note 9 is not.

Another user mentioned being able to prevent the malware from reappearing by performing a factory reset and then disabling system update mechanisms immediately afterwards. This suggests that the malware may be infecting the system update mechanism and so the device’s own update mechanism is simply downloading and installing the malware again after it’s uninstalled.

Keep in mind that a factory reset merely deletes user data, it doesn’t reinstall the OS or anything, so malware that infects the system/OS can easily survive a factory reset. One or two users on Reddit suggested that performing a system update can prevent the malware from reappearing, in which case it would be performing a fresh install of the OS and removing the source of the infection. Or perhaps a system update simply patches the exploit this malware is using.

However, the problem I see with my hypothesis is currently nobody actually knows how this malware survives a factory reset. I feel like if this were truly how the malware persists then it should be easy enough to detect but still nobody can explain it yet.

Sed Contra • November 8, 2019 12:40 PM

In view of this and also the current comments on another thread about reappearing messages, I think we have to consider rhe possibility of time travel playing a role.

“There is nothing wrong with your mobile handset. Do not attempt to perform a factory reset. We are controlling transmission … You’re travelling through another dimension, a dimension not only of touchscreen and SMS but of mind … There is a fifth dimension beyond that which is known to humankind. It is a dimension as vast as space and timeless as infinity.”

Chris • November 8, 2019 3:08 PM

Haven’t we seen this kind of thing before? One of the commentators on the ZDNet article mentioned that it affected their low end handset which was locked down (no root, no sideload capabilities, etc.). This suggests that the malware came with the device already installed and that some OEMs may be collecting on the ad revenue or it’s a supply chain vulnerability affecting vendors who outsourced the creation of their “blobs” and didn’t adequately review the code. Since this seems to be wasting a really good exploit on ad redirects, needs to be consciously installed outside of the normal process and that we know about it at all makes me think it;s a little sloppy for a state actor.

SpaceLifeForm • November 8, 2019 3:09 PM

A test worth trying to glean info.

Pull SIM, do Factory Reset.

Leave SIM out. Get on WIFI.

See what happens.

I’ll bet the problem comes back.

But, maybe not.

Chris • November 8, 2019 4:25 PM

@Sed Contra

I would gladly give up the integrity of my Android device(s!) to get in on the Microsoft IPO or, heck, to see the Grateful Dead at the Capitol Theatre.

Clive Robinson • November 8, 2019 4:55 PM

@ K.S.,

Such persistence should not be possible in a well-functioning OS.

That is a mainly invalid assumption on your behalf.

One of the problems with commodity hardware is that there is little or no chance the OS can keep up with the latest hardware additions.

The solution to this was first realy seen at the end of the 1970’s in the Apple ][, the idea behind the I/O model was later in the 1980’s adopted by IBM for their Personal Computer range, which were the forerunner of nearly all commodity PC’s these days. Which is why commodity OS’s still follow the convention as do a number of other OS’s some of which are considered “secure OS’s” with formal proofs of security[1]…

The convention is that an I/O card carries a program ROM on it with the required I/O drivers written in a memory position independent way that will be identified at Boot time by the motherboard BIOS and loaded into known memory addresses in RAM. When the OS boots it clears or overwrites much of the RAM but importantly NOT the areas where I/O drivers are loaded. The OS then runs an initialisation sub routine for each I/O driver in RAM to add interupt and jump point information so the OS can use the I/O device.

If you think back to around the time of BadBIOS, myself and @RobertT pointed out this I/O driver mechanism was an ideal way to get malware persistance that would survive an OS wipe / reinstal on hard drive etc. Further that the use of Flash ROM on I/O devices and the motherboard, without “write protection” alowed malware to overwrite any code in the Flash ROMS on either the I/O cards or motherboard…

A little while later it was found that Chinese Company Lenovo, that had purchased IBM’s Laptop etc manufacturing, was infact using exactly this technique in the BIOS of their commodity laptops, to add in their own “marketing malware”.

Both Microsoft and Linux OS’s support this I/O Device convention. As Android is based on Linux, the convention or something similar is almost certainly there. Because Google is not going to willingly relinquish the rights to push in technology to support their PII and similar marketable information collection for profit.

[1] The fact an application has formal proofs of security, does not make it secure, it needs formal proofs in the OS, for the ISA, Microcode, RTL, and all layers on down to the physics of the chips… Otherwise an attack can be launched from a lower level in the computing stack and work it’s way up the stack, much like a bubble in a champagne glass it’s effect gets bigger as it rises. Hence the term “bubbling up attack”.

Wael • November 8, 2019 5:26 PM

Right…

However, the problem I see with my hypothesis is currently nobody actually knows how this malware survives a factory reset.

Factory reset isn’t consistent across makes / models of devices. Without mentioning names, some device manufacturers use Integrity Metrics, SE Linux in enforcement mode and don’t compromise on security because they compete with other platform manufacturers. Some low-end devices only have the minimum level of security that they can get away with. Also, factory resets don’t delete SD or SIM data. Perhaps xHelper is hiding somewhere on the SD card?

How xHelper survives factory resets is still a mystery; however, both Malwarebytes and Symantec said xHelper doesn’t tamper with system services system apps. In addition, Symantec also said that it was “unlikely that Xhelper comes preinstalled on devices.”

Something fishy here. Very phishy… Obviously this news is comming from the marketing departments of these AV solution providers, for promotional purposes. So we’re supposed to believe that it’s a mystery — come on, there’re only few countable parameters to play with!

From what @Michael said:

The xHelper malware’s persistence seems to only affect certain devices which suggests this malware is not using a general Android exploit but rather some other exploit that only works on specific devices.

Yes, there’re differences in HW, SW, Drivers, etc. Also, there’re differences how different manufacturers perform factory resets (assuming they are CDD devices.) And there could be exploitable weaknesses (backdoors included) on some devices.

Last thing I expected to hear from AV Solotion providers after six months is: “It’s a mystery”! Are you freaking kidding me? goddamnit, @Vesselin Bontchev: tell me something else!

I could do analyze it in my sleep! Mystrey, my ankle — or a little above.

SpaceLifeForm • November 8, 2019 6:17 PM

@Wael

“Also, factory resets don’t delete SD or SIM data.”

Hmmm, maybe I should post this from my rooted device that has neither SIM or SD?

Not.

More testing please.

We need to find out if the exploit is going thru SS7/SIM or there is already a backdoor that allows fileless exploit to be loaded via WIFI.

I have reasons to believe it is a fileless exploit.

More testing please.

Wael • November 8, 2019 6:47 PM

@SpaceLifeForm,

We need to find out if the exploit is going thru SS7/SIM

SS7? There goes my blood-pressure!
SIM? Unlikely, but perhaps not impossible either.

I have reasons to believe it is a fileless exploit.

I don’t know which rock or asteroid you came from, but on this Unix planet, everything is a file.

More testing please

There’s enough information already. Elementary, my dear SpaceLifeWatson 😉

RealFakeNews • November 8, 2019 10:40 PM

Perform a factory reset, then dump the OS image and compare with a clean version?

Why is this so hard? I’m bored just thinking why they don’t already know.

RealFakeNews • November 8, 2019 10:43 PM

Actually… I’m fed up with this attribution rubbish.

It’s always the same – lacking information and details, for what? A news piece? Do some proper research and just state ALL the facts. Don’t just look for “who might’uv dun it”.

Dump the BIOS, dump the OS, and compare against known clean copies. There can’t be many places it is hiding and it must hit the system at some point.

Who? • November 9, 2019 1:00 AM

Android has an interesting filesystem layout in the sense it has quite a few partitions, some writable by end users (i.e. where data and apps are stored) and some digitally signed and, theoretically, unwritable for anyone that does not have the right digital certificate.

Perhaps the author, not necessarily a state actor, has discovered a workaround to overcome this protection.

As I understand it, a factory reset just formats the user filesystems, not the system, cryptographically signed, ones.

My suggestion would be reinstalling the Android operating system from a factory image instead of just doing a factory reset.

There is no magic, just misused technology.

deepview • November 9, 2019 1:20 AM

What isn’t reset at factory reset?

  • supply chain
  • DNS capture or other MITM
  • some submodule with its own software
  • baseband
  • some baseband 0day
  • other as yet (open-forensics-)unknown side channel
  • hardware side channel via THz management module or so, and ubiquitous kraken APs
  • like, did you look into G.hn homeplug routing technology?!
  • or something with a new BT or LoraWAN or similar.

This obviously is a call to more thourough methods in forensics.

Ads could be a red herring regarding a mole@supplychain or so.

There may be too much complacency because of an illusion of “someone will do it” fostered by worldwide-access-induced we-will-ultimately-know-everything illusion. They menace to crack down on whistles so much that this might not be true any more.

Much of research depends on single individuals doing things. In other words, do free forensics, free minds in IT and free speech have enough redundancy?

The hardware supply chain has little redundancy these days, arriving at crazy levels even menacing the power systems of the usual suspects for world domination.

Why would this be different elsewhere? (Please prove me wrong on this last worry.)

We urgently need to replace divisiveness in the minds by universal love.
We need to use tech for that purpose, otherwise it will disappear.

deepview • November 9, 2019 1:27 AM

@Wael

on this Unix planet, everything is a file

This is your weak spot.

An exploit residing in memory resides in a file (like: kmem), but this doesn’t mean anything because you don’t learn anything about getting to the root of the problem.

You need to listen better what the other side really wants to express.

As long as you don’t know everything, don’t be too sure about yourself.

Clearsightedness comes from humility.

Who? • November 9, 2019 1:59 AM

@ deepview

Wael, one of the most respected members of this forum, is right when he says everything in a Unix system is a file. Standard files, devices (either block or character ones), domain sockets… anything from a printer, a keyboard or a framebuffer up to filesystems and disks themselves are files on a Unix system.

This one is the simplicity and beauty of Unix.

By the way, /dev/kmem itself is a file but I fear it does not work in the way you think. It is a device that acts as an interface to the kernel virtual memory. Whatever is stored on the smartphone/tablet memory is lost as soon as the device is restarted.

As I said there is not magic, just misused technology.

C U Anon • November 9, 2019 2:15 AM

@ deepview,

An exploit residing in memory resides in a file (like: kmem), but this doesn’t mean anything because you don’t learn anything about getting to the root of the problem.

Depending on your world view a file tells you precicely nothing but it’s binary contents. That is it is just another “bag of bits” data container.

To learn anything else you have to go to what is often a flat file database known as a “Directory” which contains file attribute information and a pointer to the data structure on the storage medium that has further pointers to the individual data blocks.

Now on looking at @Wael’s posting it was obviously ment to contain a degree of humour not terminological exactitude.

So as you say,

You need to listen better [to] what the other side really wants to express.

As for,

As long as you don’t know everything, don’t be too sure about yourself.

It’s not just logically impossible to “know everything” it’s easy enough to show that even the Universe can not store everything there is to know. Which whilst it might appear trite to many has significant implications in certain areas of science and philosophy, as well as practical implications in information security.

deepview • November 9, 2019 2:26 AM

@Who

The difference between kmem and other files is that certain files sit somewhere where you can observe changes when turning off the device hard.

kmem will be gone.

So mixing the two is relevant from a “how to read it” point of view, but is irrelevant here because there might be an observability problem.

So that’s why I said conflating the practical differences is a weak spot.

Wael • November 9, 2019 3:30 AM

@deepview,

This is your weak spot.

And your strong spot 😉

you don’t learn anything about getting to the root of the problem.

Speak for yourself. The fact that you don’t has nothing to do whatsoever with others ability to learn something about it.

You need to listen better what the other side really wants to express.

Repeating to myself: Listen better, other side! … [100 Times] … Listen better, other side… ummmm. myopic view.

Clearsightedness comes from humility.

I’m the most humble human on earth.

but is irrelevant here because there might be an observability problem.

Whiskey Tango Foxtrot are you talking about?

Weather • November 9, 2019 5:13 AM

Is Arm the same as x86 with rings,real/protected mode?

Kmem being virtual should only dump the ring your in, and it won’t be at the physical address, you’ll need to call some ram interrupts and copy that to storage, but be in real mode, which only ring 0 can do.

Dave • November 9, 2019 5:19 AM

That level of persistence speaks to a nation-state actor.

Or some kid who’s discovered an Android 0day that allows persistence. If it was nation-state they’d keep something this powerful secret, if it was security researchers they’d notify Google or sell the exploit depending on their leanings.

Dave • November 9, 2019 5:24 AM

@KS: If we are doing paranoid conspiracies, a much better story would be if Apple is behind this malware

Naah, if we’re doing conspiracies it has to be the Illuminati. The ads are just a cover for the fnords.

Weather • November 9, 2019 5:49 AM

Set the coredump to kernel, and crash the Os ,psec had a tool for windows, not sure on Linux.

SpaceLifeForm • November 9, 2019 12:12 PM

Fileless

Is a misnomer.

It’s means not written to a backing store, examples being spinning rust or flash.

It only exists in ram.

I did not come up the name, but I’ll bet someone decided that a name like

The-never-written-to-storage-exploit

was deemed too cumbersome.

Wael • November 9, 2019 1:14 PM

@ SpaceLifeForm. @C U Anon, @Who, @deepview, all

Is a misnomer(Fileless.)

I understood what you meant the first time. What we’re discussing here is how malware (adware, or whatever form malcontent takes) persists across Factory Reset cycles, right? Sweet.

@deepview mentioned kmem, observability issues, and:

kmem will be gone.

Ok, now that it’s gone: where did it come back from? If not from a file somewhere on local storage, or a file [1] somewhere on a CC server, then from where? It got recreated out of thin air? Sayng “kmem” without any further elaboration doesn’t really answer the “how does malware persist across Factory Reset cycles”, does it?

[1] There are other possibilities that I want to avoid in this discussion.

SpaceLifeForm • November 9, 2019 2:52 PM

@Wael

The easy answer, even if no SIM or SD card, is that the malware comes back in via the cell radio or WIFI.

That is, it truly is a fileless exploit.

It may have lots of steps.

But after an hour, it’s back.

It’s very important to remember, that even sans SIM, the cell radio still works.

This is how one can call 999/911 on an old phone that has no service.

So, testing scenarios is important.

Factory Reset, no WIFI. Does it reappear?

I have reason to believe, it is a very deeply buried backdoor. Very deeply buried in silicon.

The computer under the computer under the computer.

Wish I was joking, but I am not.

Turtles all the way down, buried in silicon.

SpaceLifeForm • November 9, 2019 3:22 PM

@Weather

“Is Arm the same as x86 with rings,real/protected mode?”

It’s exactly the same, but different.

ARM has Ring 0 (kernel), and Ring 3 (Userland)

Only your Hairdresser knows for sure what really happens in Ring 1 and Ring 2 on x86_64.

Wael • November 9, 2019 3:34 PM

@SpaceLifeForm,

The easy answer, even if no SIM or SD card, is that the malware comes back in via the cell radio or WIFI.

First of all, I have not read much about xHelper; I don’t have the time or desire to do so. What puzzles me is AV Solution providers who claim it’s a mystery, and I shared my opinion about this earlier. They have the binaries and the devices and made claims that (copied from @Bruce’s thread details:)

however, both Malwarebytes and Symantec said xHelper doesn’t tamper with system services system apps. In addition, Symantec also said that it was “unlikely that Xhelper comes preinstalled on devices.”

Why do they give us the impression that they have not gone through narrow-down tests like the ones you mention (and I am sure they have done so, and a lot more)? Several possibilities:

1: Responsible disclosure. We’re basically giving them the benefit of the doubt
2: News came from marketing departments that like to bring their name out for marketing purposes. a little FUD isn’t too bad for business. Keep in mind that often times Marketing folks do not consult with their technical counterparts before they “go public”
3: They were coerced to take a sip
4: They know exactly what’s going on, but are working on a “parallel construction” scenario to attribute the thing to rocket-man or some other boogie person.
5: … a lot of other possibilities

But what’s not acceptable is: “It’s a mystery”.

This is how one can call 999/911 on an old phone that has no service.

Right… links to previous discussions on SIM-less topics omitted (for clarity.)

Wael • November 9, 2019 4:18 PM

Hmmm…

We strongly believe that the malware’s source code is still a work in progress.

Strongly believe, eh? Is that what your scrum master told you in this PI session? And as I said previously:

They know exactly what’s going on, but are working on a “parallel construction” scenario

Bingo! A case in point where two departments are out of sync: script-writing and code-cutting departments are in dissonance. Script-writers are behind on the parallel-construction attribution details. And the code-cutters are still scouring stack-exchange, wikipedia, the dark web for missing components. Apparently some schmuck copied adware instead of the malicious payload and set the program back by a few sprints.

Case closed 🙂

SpaceLifeForm • November 9, 2019 4:24 PM

@Wael

I’m going to do a test.

Because I can. And will.

I will note results later.

Because it will take time.

First step done. Will take 24 hours before further steps.

This will take at least 48 hours before I have any clues on the vector.

But, I’m very confident it exists.

So, my first test is to eliminate one of the possible vectors.

And, important to note. I will not be surprised that my tests come up negative, only to reappear weeks from now.

But, I do have confidence that I will spot some ‘stuff’ of interest.

I’ve been around a while.

You can observe a lot just by watching.

Wael • November 9, 2019 4:28 PM

@SpaceLifeForm,

If you share the analysis report before any of the AV boys, I’ll have a small gift for you.

SpaceLifeForm • November 9, 2019 4:40 PM

One other thought.

Does ‘Airplane Mode’ really mean the radio is off? Totally doubtful.

Anyone have ANY proof that ‘Airplane Mode’ really means that the cell radio is really off?

I do not believe that is reality.

Or does it really mean that you get no notifications?

Wael • November 9, 2019 5:00 PM

@SpaceLifeForm,

There are a few “radios”: WiFi, Cell, BT…

According to FAA, devices are prohibited from transmitting radio signals (more details in the link.)

I would imagine, in airplane mode, the RIL (Radio Interface Layer) that connects your MDM to your rich app ACPU is disabled. But I remember that MNOs can detect that your phone is in Airplane mode… whatever the case may be, run your tests in a shielded environment. Who knows what the regulations look like in different countries or what the differences between a “ranged phone” and “trade phones” are. Remove all assumptions from your test procedures.

SpaceLifeForm • November 9, 2019 5:11 PM

For this test, I’m going to intentionally mess up known WIFI passphrases of WIFI APs that it has seen.

This to make sure, that even in Airplane Mode, in theory, it should not be able to connect to internet via WIFI.

In theory.

Theory fail.

On Android, you not remove an AP/SSID that is visible.

SpaceLifeForm • November 9, 2019 5:27 PM

Android remembers AP/SSID that you have sucessfully connected to and will not let you ‘forget’ them, if in range. You can not change the passphrase or forget SSID until you are out range of the radio signal.

That be called ‘tracking’ in my book.

Google probably calls it a User Experience feature.

SpaceLifeForm • November 9, 2019 5:42 PM

@Bong-Smoking Primitive Monkey-Brained Spook

These are WIFI APs that I am not admin for.
I can get most to do what you note, but it will be easier to just move out of range.

The interesting point, is that you can temporarily ‘forget’ AP/SSIDs that are visible, as long as you never connected to them.

Of course, they will re-appear.

Android is always scanning.

Recall the Google drive-by WIFI vehicles, the geo-locate.

SpaceLifeForm • November 9, 2019 7:40 PM

My test is getting very interesting.

After changing locations, and having no valid WIFI (not connected over WIFI), the AP/SSID that I wanted to disappear/break, but could not due to being in range, no longer appears in the list.

But, it has to still exist in storage somewhere at this point, because I can not see them to either change the passphrase or forget them.

It’s as though there is some kind of anchor tracking going on.

Thus, the WIFI user interface always wants you to have a least one working connection (likely would include cell), before you are allowed to manage the others.

Note: this test involves no SIM, no SD card.

I’m certain, that if I go back to prior location, it will connect again.

So, my test is going to take much longer.

Weather • November 9, 2019 8:41 PM

@spacelifeform
Download a shell app, head 1gig of kmem,then hex search for a Ap that is known, repeat back here, to get the struct.

Potkorook • November 10, 2019 1:33 AM

This has some elements reminiscent of a piece of malware I played around with on an older friend’s WinXP PC one day. It had elements scattered around, but the most important one was a little file stuck into the middle of the root directory (C:\ on Windows boxen.). And that kept coming back whenever he got on the Internet.

So I deleted it once we were off the Internet and using the magic of Notepad, saved an empty file with its name then renamed it to an exe file. It never reappeared, giving me the time to go through and track down its other bits and peces, and wiping them off his PC.

I suspect one could do something of the sort with this xHelper, which I take is not relocatable? Symantec’s already shown us some disassembled routines. What could be done is reassemble the code minus the most offensive stuff – software patching systems do this all the time – including enough “functionality” that its makers won’t suspect a thing, including of course the “xHelper Phone Home” functionality but disable the update functionality so that they can send any payload they like and it’ll enjoy /dev/null where it wants to be. And include tracker traces so that the malware leads straight back home.

Oh and BTW, if Symantec have disassembled it, it’s not “file-less” because you disassemble files – binary generally – but you can’t disassemble a non-file.

Clive Robinson • November 10, 2019 2:00 AM

@ SpaceLifeForm, BS PM BS, C U Anon, deepview, Wael, Weather, Who?, and interested readers,

I’m going to do a test. Because I can. And will. I will note results later. Because it will take time.

May I urge a little caution for all before people leap in.

Firstly go read the history of “BadBIOS” and the researcher looking for it. Their reputation got tarnished baddly by journalists who played the “Mystery” card, and for a bit of sensationalism pushed the researcher into what sounded to nearly everyone else as “wild speculation” and “fantastical imaginings” all “driven by wild paranoia”.

Further look up how the “usuall suspects” of the time on this blog had already done all that BadBIOS allegedly did, years befor hand and accurately described here what you had to do to get it to work.

That is,

1, We had made high frequency audio communications work during the 1980’s/90’s.

2, We correctly diagnosed why modern laptop speakers and microphones would work better.

3, We pointed out the old I/O Driver software in ROM mechanism, and described how it worked and why it was there and would give malware persistance beyond hard drive wipping and replacing with brand new hard drives.

4, We had also pointed out at that time and others that the Software Industry appears to not remember or learn it’s own history. Which is why attacks from the 1980’s/90’s were “finding new life” around a quater of a century later.

Which few people even on this blo believed,, untill a couple of young Uni researchers did what we had said, and put two laptops in a corridor and then wrote it up… (moral you are not the inventor/discoverer unless you’ve “published a paper”, the honour belongs to those with a paper even though they’ve only copied your work…)

But whilst what appears as “wild speculation” to many may actually be true, it’s best to show documentation based on the laws of physics or other “known work”.

Also watch out for the “William of Ockham’s Razor trap”. Occam’s razor realy only applies to thought experiments where the subjects involved are inanimate or can have no free will. Where however subjects have free will or concious thought their behaviours become to complex due to what can be called “Hidden variables”. Obviously when dealing with malware writers their aim is longevity of covertness of method, thus one or possibly two “tricks” will be used that are disguised or hidden from plain sight, but the rest of the code will follow the usual rules.

Thus alow for one or at most two “fantastical sounding” methods but don’t make the mistake of thinking the whole thing will be a “mystery” because it will not.

Also keep in mind the “delivery payload” relationship. That is remember there is no necessity for the “payload you find” to have the “delivery method inside”. Even when the malware has replication involved, a delivery mechanism can have what are in effect two or three payloads that chain. That is the one that causes the user problems needs no persistance or replication methods, the one responsible for ensuring persistance needs no replication nor problem payloads just knowledge of how to check for the problem payload, and where to get a replacment from. The replication method is only needed for propergation of the malware and once it has successfully reproduced on another computer it can then put the peristence payload in place then “self destruct”.

That way investigators get effectively trapped at the wrong end of a one way tunnel. Not being able to work backwards they have to use other methords to try and catch the replication or even persistance payloads. Which can take a long time.

Wael • November 10, 2019 3:26 AM

@Clive Robinson, @SpaceLifeForm, BS PM BS, C U Anon, deepview, Weather, Who?, Potkorook , and interested readers,

BadBIOS! That was some time ago. Two threads, if the cobweb in my skull is right.

(moral you are not the inventor/discoverer unless you’ve “published a paper”, the honour belongs to those with a paper even though they’ve only copied your work…)

Honesty is a faint whisper, in the midst of an lintegrity-lessness and plagiarism dull cacophony.

I have my earplugs in.

Oh and BTW, if Symantec have disassembled it, it’s not “file-less” because you disassemble files – binary generally – but you can’t disassemble a non-file.

That’s tight! You dump it.

tds • November 10, 2019 4:31 AM

Late to the party, but might the above be a reason to consider new, used, or Apple’s factory refurbished hardware? For example, iOS devices. OT, but, of course, Macintosh computers readily run other Unix, Linux and Windows, too, AFAIK.

https://www.apple.com/shop/refurbished ; iPhone 7 $399 & up

SpaceLifeForm • November 10, 2019 11:27 AM

My test plan will not work.

I can not cage WIFI/BT and leave radio non-caged. Or the reverse.

And, as expected, even if you can remove an SSID from the list, it does not really forget.

Once you move back into range, it will connect again. (assuming passphrase has not changed in the meantime)

It’s very subtle how it works, but sure looks like a good way to do geotracking.

Even if in Airplane Mode or sans SIM.

And there are so many WIFI enabled printers around! That become fixed points of reference.

SpaceLifeForm • November 10, 2019 1:40 PM

@Weather

I’d like to dump kmem, but I have a catch-22.

For some magical reason, about 2 years ago, my microSD card was no longer visible.

The card is fine. I verified elsewhere.

So, on this rooted device, I no longer had my /usr/local, which really ticked me off, because I could no longer access my toolchain.

I was actuallly native compiling on this device. I designed for that. In theory, I could load the toolchain into ram, but ram is limited, so a 100MB toolchain was best left on sdcard since mostly readonly.

Yes, builds were slow, but worked.

So, the only way I can dump kmem is to get my wifi setup going again, where I can ssh/telnet in, and dump it over wifi to pc.

Alas, time is limited currently.

After reading thru the various forums, and based upon my observations for years, I think what we are looking at is:

A built-in backdoor in Android using the core OS (no need to modify /system), AND the channel to the builtin backdoor via Chrome.

The problem: If you think your backdoor is locked tight, it may not be.

The hinges could be on the wrong side of the frame.

If someone has discovered the exploit path, and is IN POSITION on net, then, ‘Houston, we have a problem’

I have to agree with @Alejandro on this.

I do not believe the route matters. WIFI or CELL will both work for exploit purposes.

SpaceLifeForm • November 10, 2019 2:08 PM

@Clive nails it.

That is remember there is no necessity for the “payload you find” to have the “delivery method inside”.

Weather • November 10, 2019 2:13 PM

You can use pipes and std redirects,
Head /dev/kmem ) grep syntax + 100 bytes ) file.DMP

You can get file timestamps, diff usages like they reverse patch’s, plus if you find the code, the entry point will be close by or vice Verser.

SpaceLifeForm • November 10, 2019 6:01 PM

Maybe there is no backddor.

Maybe it a just a Glitch.

(rowhammer attack via javascript)

https[:]//www.vusec.net/projects/glitch/

Gordon • November 10, 2019 6:27 PM

State sponsored actor and being noisy are not mutually exclusive in all cases. The first case that came to mind is that there are pariah states where monetizing malware has higher than normal value. More obliquely, there are cases where observation of response could be the reward. This may be sufficiently low value in the state arsenal to merit using as a response yardstick.

Wael • November 10, 2019 11:23 PM

@SpaceLifeForm,

Maybe it a just a Glitch.

Hmmm. Interesting! GLitch [1]

Our PoC heavily relies on the insights we recovered by reverse engineering the architecture of our target systems: the Snapdragon 800 and 801. This means that our PoC works only on phones such as the LG Nexus 5, HTC One M8 or LG G2.

May explain why some devices are not affected. Still doesn’t (fully) explain persistence across Factory Reset. Did you try using browsers in your test?

[1] The technique is named GLitch with first two letters capitalized because it uses a widely used browser-based graphics code library known as WebGL for rendering graphics to trigger a known glitch in DDR3 and DDR4 memory chips — https://thehackernews.com/2018/05/rowhammer-android-hacking.html?m=1

me • November 11, 2019 5:26 AM

As far as I can tell (and google), factory reset does not erase SIM and data on SD card. Perhaps the xHelper leaves some specially crafted “landmines” on SD card. I mean, executing arbitrary code by viewing a picture is not unheard of.

AT • November 11, 2019 12:43 PM

You don’t need a nation-state to develop persistence against faculty resets – you just need to read the security literature.

SpaceLifeForm • November 11, 2019 1:24 PM

@Wael, @me

I’m thinking there is no true persistence.

I’m thinking, the user, after factory reset, get’s online, and is re-infected once online.

It may be a Javascript rowhammer attack to get root. Or a different exploit path.

But, the rowhammer attack looks good.

And, if that is really it, then they need to disable Javascript.

What is really interesting, is that why would the attackers (if they really got root), why would they make the xHelper app visible to some users, and not others?

And be obnoxious about it, via pop-up ad-sites?

I can agree, this is a work-in-progress.

And, the reason to be obnoxious?

Because, the attacker will be able to track that the attack actually worked.

This then leads to the question:

Who is IN POSITION to serve the Javascript rowhammer attack to the users browser?

Is it only old Firefox or Chrome versions that are exploitable?

Or, is the Javascript rowhammer attack possible on any device, just easier on some?

I suspect that it is feasible on any device, but that it is easier on small ram devices, because ASLR is constrained.

Wael • November 11, 2019 2:40 PM

@SpaceLifeForm, @me,

I’m thinking there is no true persistence.

Either that or the thing is preinstalled, despite what the AV boys are saying.

I’m thinking, the user, after factory reset, get’s online, and is re-infected once online

There’s an initial prerequisite that the user side-loads this app. There’re no reported incidents of devices affected before that initial step. The question is then: what did side-loading the app install that keeps triggering infection through an online channel? There must be something that persists on the device after that initial side-loading flow.

It may be a Javascript rowhammer attack to get root. Or a different exploit path.

  1. Did the user need to use the browser? Perhaps that’s a test you can run, right?
  2. Were there any reports on devices being rooted?

But, the rowhammer attack looks good.

Could be one of the steps. I don’t know.

Who is *IN POSITION* to serve the Javascript rowhammer attack to the users browser?

We have to establish that this is the method!

Weather • November 11, 2019 3:20 PM

@all
If Android has anything like the windows registry, getting a key the can open a door, like google automatic OS update, or Puk of the Sim, it could be a huge list.

SpaceLifeForm • November 11, 2019 5:15 PM

@Clive nails it.

That is remember there is no necessity for the “payload you find” to have the “delivery method inside”.

@Wael

“There’s an initial prerequisite that the user side-loads this app. There’re no reported incidents of devices affected before that initial step”

No “REPORTED” incidents.

Wael • November 11, 2019 5:59 PM

@SpaceLifeForm,

No sideloading required.

So xHelper gets installed without users installing it? Not what the reports say!

I’m 99.99% certain it is Javascript rowhammer

4 nines!

Bruce Schneier • November 12, 2019 9:01 AM

@Clive Robinson:

“I’m glad you and others are now feeling it’s safe to say.”

Do you think there has been a change? I don’t think there is. There has always been a bell curve of attribution styles, from optimistic to conservative. I don’t even think the standards of attribution have changed very much, if at all.

SpaceLifeForm • November 12, 2019 1:59 PM

@Wael

“Did the user need to use the browser? Perhaps that’s a test you can run, right?”

Like I said, I’ve seen this movie before.

The attack will want to launch (one of) your browser(s).

If you do not have multiple browsers, then it will just immediately proceed to launch your builtin browser, to display a web site page.

“Were there any reports on devices being rooted?”

The user will never know that an attacker got root. It will never become a rooted device where the user can login as root, or ‘su’, etc.

The attack is temporary root, to install the payload.

And, because the xHelper app is now ‘installed’ (to /data), the app is now persistent across reboots.

Until next ‘factory reset’ which wipes /data

And, so as long as the xHelper app can function, three things are accomplished:

The xHelper app can call home, and reveal to the attacker that the attack worked.

Via tracking, the attacker no longer has to inject the javascript rowhammer. Which, may be semi-visible to the user due to unresposiveness, raising suspicions.

And, the obvious, it can talk to the C2 for further instructions.

The xHelper app certainly does not run as root. The permissions model of Android requires that the app gets it’s own userid, different from other installed apps.

But that does not mean that the app can never get temporary root later.

And then exfiltrate back to C2.

SpaceLifeForm • November 12, 2019 5:25 PM

@keiner

Sailfish browser still has a Javascript interpreter.

They can all be crafted via Javascript to carry out a Rowhammer attack.

The attack will have to be crafted for the Javascript engine and the hardware platform combination.

So, it takes work.

xHelper may just be a POC on easilly attackable platforms at this point in time.

Wael • November 12, 2019 9:18 PM

@keiner,

…and if you can’t make sense of the story:

Non-linear war, confusion,.. all makes sense. The only thing I don’t get is why he doesn’t move his right arm in his distinctive stride. But it ain’t no mystery:)

keiner • November 13, 2019 11:11 AM

“xHelper may just be a POC on easilly attackable platforms at this point in time.”

…this whole thing is so 100% Putin-joke-pattern…

SpaceLifeForm • November 13, 2019 12:47 PM

@Wael, @me

“This means that our PoC works only on phones such as the LG Nexus 5, HTC One M8 or LG G2.”

It’s not sdcard, because the LG Nexus 5 does not have sdcard.

What they have in common:

2GB ram
GPU Adreno 330
Older Android

Clive Robinson • November 13, 2019 2:57 PM

@ Bruce,

Do you think there has been a change?

Yes I do, atleast outside of the US MSM (which thanks to EU legislation is now not accessable on equitable terms).

The change is from unquestioning acceptance to more nuanced questioning or care to ensure that the consumers of the news are warned that it is at best unverified.

Further,

I don’t even think the standards of attribution have changed very much, if at all.

Whilst I would agree that the “methods” have not changed even those publishing the results are becoming more cautious about what the attribution means. But perhaps more importantly those outside the process but with an interest in it are begining to understand just how hard non HumInt attribution is.

Whilst some may not like me asking the “Does it meet primary evidence for a criminal court?” test, the simple fact is more people are realising that unless it does it is at best “opinion” if not “hearsay”. Thus they are gaining insight into the “Politics of Attribution” and how policy can be sought on very shaky ground.

The simple fact is at the end of the day attribution has been used as a football and kicked from pillar to post by those with their own agendas political, business, or otherwise. People are waking up to that and are thus trying to seperate method from agenda.

What has partialy helped in this change, is one nation actually going “kinetic” on cyber-crime.

In the back of increasing numbers of peoples minds in many parts of the world is the realisation that their neighbours child up in the back bedroom of the house next door could bring hellfire missiles down on their heads. And for all the propaganda about smart weapons collateral damage happens… Thus the usually nebulous nature of cyber-attribution is not going to make such collateral damage any the less, more probably the opposit.

But those only a fraction closer to the attribution problem know, it’s not that difficult to set up a cyber-crime launch point anywhere you care to. All it needs is a seat, laptop and network connection all available around the corner in your local coffee shop, (and even the seat is optional. Or likewise even a car and a neighbours insecurely configured WiFi router. The pictures last year of the Russian’s picked up in a car park adjacent to the Organisation for the Prevention of the use of Chemical Weapons (OPCW) by the Dutch authorities made lurid if technically inacurate reading in many MSM outlets[1]. Whilst the technical errors are forgotten, the lurid personal details are remembered as is the apparent ease of attack.

These are the practical realities of life and they are slowly but surely instilling themselves in peoples thinking.

Which I hope as others do will take much of the self interested rhetoric out of what is a complex issues, that are over due to be resolved by thoughtfull international treaty, before more nations progress down the balkanisation of the Internet[2].

[1] https://www.dailymail.co.uk/sciencetech/article-6239745/Russian-GRU-hackers-used-budget-mobile-phones-high-grade-Wi-Fi-equipment.html

[2] https://www.independent.co.uk/life-style/gadgets-and-tech/news/russia-internet-disconnect-experiment-isp-cyber-war-putin-data-a8773961.html

Nix • November 14, 2019 9:15 AM

The convention is that an I/O card carries a program ROM on it with the required I/O drivers written in a memory position independent way that will be identified at Boot time by the motherboard BIOS and loaded into known memory addresses in RAM. When the OS boots it clears or overwrites much of the RAM but importantly NOT the areas where I/O drivers are loaded. The OS then runs an initialisation sub routine for each I/O driver in RAM to add interupt and jump point information so the OS can use the I/O device.

This is more or less accurate of ISA cards but is highly inaccurate for PCI, so you’re only thirty years or so out of date. PCI cards can still have option ROMs, but only a few do, and in most cases all that is actually used from there is data tables. (UEFI systems can have arbitrary per-device PXEs on there, too, and can contribute runtime services, but those are fairly nailed down.)

Both Microsoft and Linux OS’s support this I/O Device convention.

Honestly… no. Those option ROMs that contain code at all almost always contain either x86 real mode code (seriously) or x86 PE binaries for UEFI, and outside a few network cards (used only for PXE booting over the net) and the inevitable hellzone of graphics cards nobody does that at all. They do not contain ARM code, and while UEFI in theory supports an interpreted non-x86 portable machine language specifically for this reason it is as far as I know entirely unused by anyone. If an ARM platform wants to execute code out of option ROMs, it has to use an x86 interpreter to do it. In practice this is so inconvenient that such devices are simply unsupported on ARM. (Those graphics devices that are supported are usually either ARM-specific and wired in via IP blocks, or contain specialized device-specific arch-independent tables that the OS’s driver knows how to interpret, like Radeon video cards.)

What is widely used and provided by the device are ACPI tables, but you can’t practically spread malware that way as far as I know.

But this is all academic anyway because mobile phones do not ever boot using UEFI (they usually use u-boot), do not support expansion cards at all, neither PCI nor (ha ha) ISA, and I’ve never heard of a phone supporting ACPI: that’s a server-side thing in the ARM world. They have hardwired tables (look up ‘device tree’) instead. No option ROMs, no executable code provided by a potentially hostile user-provided devices on cards, no ability to add user-provided devices on cards, nothing.

SpaceLifeForm • November 14, 2019 2:54 PM

@Nix

“No option ROMs, no executable code provided by a potentially hostile user-provided devices on cards, no ability to add user-provided devices on cards, nothing.”

All good points. Until the user hooks up their phone to their potentially hostile user-provided device, their PC.

Are you sure there are not issues with charging cables? USB/Lightning?

Cellebrite can get in, and dump.

I’ll just note, that, oh, about 2 decades ago, Microsoft wrote their own AML compiler, instead of using the Intel AML compiler.

So, I would not want to safely conclude that backdoors can not be planted into ACPI.

Backdoors in Silicon.

Clive Robinson • November 14, 2019 6:21 PM

@ Nix,

This is more or less accurate of ISA cards but is highly inaccurate for PCI,

Actually what they put in place for PCI was the use of a Forth interpreter (IEEE 1275-1994 “Open Firmware”). The advantage of this was not only CPU ISA independence, but “tighter code” which back in thr 1990’s was still an important consideration.

But you go on to say,

PCI cards can still have option ROMs, but only a few do

Which means you acknowledge that what was being discussed which was “the mechanism in the OS” is still there (called EFI byte code or EBC it’s analogous to “Open Firmware”, but due to UEFI only supporting little-endian CPU’s a lesser equal).

But then we know the BIOS ROM was still there as well because of Lenovo using it to get persistant malware well into this century. So your comment of,

so you’re only thirty years or so out of date.

Is not true is it?

But my intention was to give the history of why OS’s have these holes in them even to this day all be it by “binary blobs in Flash ROM”. Apple recognised the Hardware I/O problem, probably before you were born back in the mid 1970’s getting on for half a century ago. And we still have the same hardware issue in Android devices irespective of the CPU ISA, even though the hardware is mostly not on easily removable I/O cards. Google lets manufacturers put in persistsnt code in various forms, the manufacturers for production reasons use Flash ROM that can be overwritten at any time. Thus the security implications of such issues still exist in modern commodity OS’s even if they might be marginally more dificult to exploit[1].

I could go through your other comments point by point, but it would be fairly pointless. Because it’s obvious you did not read and take on board @K.S.’s comment of

    Such persistence should not be possible in a well-functioning OS.

And my concluding paragraph of,

    Both Microsoft and Linux OS’s support this I/O Device convention. As Android is based on Linux, the convention or something similar is almost certainly there. Because Google is not going to willingly relinquish the rights to push in technology to support their PII and similar marketable information collection for profit.

Now if you disagree with the fact I think Google or it’s employees have in effect “backdoored” Android in several ways, then please feel free to argue against that. But I suspect if we wait long enough someone will find such a backdoor, after all they have with most of their upgrades to the Chrome browser put more and more code to fascilitate their business model of “steal it all” with regards to users PII and habits etc. In effect just like Facebook has done to it’s users and Microsoft are now doing with their invasive “telemetry” and god alone knows how many application writers for Android and Apple platforms. Oh and increasingly all those IoT devices built in China but designed by the likes of Amazon[2]…

[1] As I’ve pointed out in the past “code signing” means next to nothing other than “A person with access to the private key hashed a “bag of bits” and then encrypted the resulting hash with the private key”. That is it attests to nothing about the contents of that “bag of bits”. As has been proved on a number of occasions, the process can be subverted, by just a few people, despite the best efforts of the many… It’s also a good example of why “golden keys” that those in Law Enforcment argue for are a very bad idea.

[2] Amazon have realised that there is a lot of money to be made by selling access to your “home security” devices, and apparently they have not had trouble finding customers for that access. Likewise the manufacturers of Smart Meters are looking to make money on access to your utility usage… Mad as it first sounds, a Japanese company has found a way to sell “electronic toilets” to “the worried well” it has a camera that views your motions and makes some rudimentry analysis on them (see “Bristol Stool Scale”). Connecting such a device to a communications network such as the Internet or GSM network would no doubt be of great interest to US Health Care Insurance Companies who would probably salivate at the opportunity to use it to make adjustments to your premiums to their benifit, just as they tried to do with the apparently now ill fated Fitbit and similar “Internet connected health lifestyle wareables”…

Nix • November 27, 2019 6:13 AM

@Clive Robinson, you’re moving the goalposts. You were talking exclusively about option ROMs and how they could be used to attack mobile devices running Android because obviously Android devices have the same thing (hint: they don’t), but now you suddenly claim you were talking about the BIOS as an explanation for why your stuff about option ROMs wasn’t decades out of date. BIOSes might have gone away rather later in the PC world, but Android devices have never had a BIOS so this is irrelevant to your main argument. Nor do they use UEFI.

As an analogy to Android devices this isn’t very good either. They do have flashable firmware, but this firmware is much better protected than a PC BIOS ever was (the only bit of a PC that is remotely well-protected against reflashing by hostile code running as root is the ME on Intel platforms and possibly the BMC if you’re very lucky), and crucial parts of it (e.g. the bootloader) are often nailed in place with e-fuses that if they can be attacked at all take voltage-slamming attacks etc to get past — not the sort of thing that can be done undetectably, or on a mass scale.

Clive Robinson • November 27, 2019 7:12 AM

@ NIX,

you’re moving the goalposts

Not realy as I said,

    But my intention was to give the history of why OS’s have these holes in them even to this day all be it by “binary blobs in Flash ROM”.

My intention was to give more background, because of the comments you had made, that were shally we say “overly selective”

Thus I also said,

    I could go through your other comments point by point, but it would be fairly pointless. Because it’s obvious you did not read and take on board @K.S.’s comment

Which you still have not done. All you appear to be trying to do is maintain a thoroughly blinkered viewpoint that does not look at that you don’t wish to see.

There have been past failry famous observations about the difficulty of getting a person to see a point of view when their salary depends on them not doing so…

Your choice of where you go from here, but don’t expect others to follow on your quest what ever it may be.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.