I think I found a new malware on Windows 10 mobile

[KimRM]

Okay, then explain *exactly* how malicious code is prevented from being published in the store?
I can publish a utility, and obtain a driver cert, and as long as it matches my "company", and meets certain guidelines, I'm allowed to publish.

While this makes it *appear* closed, it's really not that hard to circumvent, if someone decides the attack surface is sufficient.

It's not only "guidelines". You have to declare what you want to have access to in the apps manifest. If you don't it won't have access. The apps are tested based on what you declare before they get to be published in the Store.

 

[Pete]

Nobody bothered due to small or near non-existent market share.

This is not entirely true. The guys over on XDA (and other places, I'm sure), have tried. They're intelligent guys and some of them would love to be able to prove a vulnerability in Windows Phone. There has been some hackery on dev unlocked devices, there's been no case where any vulnerability can be crafted to attack a "normal" user.

Windows Phone has a reputation for being secure, and any cracks in that armour would be quickly and widely reported. I've never yet seen such a case beyond simple DNS redirection (as in this thread) and phishing attempts.

 

[Krystianpants]

That's interesting, the router wouldn't have occurred to me, but it makes perfect sense. I bet buffer overflows are pretty common in unchecked router code, given the packet issues and such. There's a lot of alignment being managed, and I'm sure they're try to squeeze every last bit out of transfers.
I would hope the larger manufacturers would run at least basic code checks on their firmware work, but if you're writing some routines in assembly to optimize, then there's not much that I know of in terms of scanning tools...

Yah I read an article not too long ago how many home routers are susceptible to different exploits. Even allowing remote access by crafting a packet in a very specific way that leaks into other memory locations and allows configuration information to be sent in the packet.

Nobody bothered due to small or near non-existent market share.

Well Mac OSx has had the most vulnerabilities even though it's a small market share. If they were exploited or not is tough to say. But since it is based on microkernel approach of *nix and nix has a huge amount of vulnerabilities which even travel to android, it's possible. But Apple is quick to patch things up while android isn't. There's still some out in the wild that Google won't even fix because they can't. But they usually are fine if the devices aren't rooted.

Anyways, I don't know about windows 10. But there was a hackathon trying to get into ios/android/windows phone. The others they were able to get full permissions pretty quickly while on windows phone 8 the most they got were cookies from the browser and they couldn't get anything beyond that. And these people prepare before hand as there are big prizes and such.

Who survived this three-way hackathon: Android, iOS, or Windows Phone? | SciTech | GMA News Online

 

[Krystianpants]

It's not only "guidelines". You have to declare what you want to have access to in the apps manifest. If you don't it won't have access. The apps are tested based on what you declare before they get to be published in the Store.

Exactly and then on top of that MS signs the application. And even if you publish something malicious it is contained in its own virtual environment and within a randomly generated memory location. So the worst you could do is get someone's contacts if they allow you permissions. Anything the app tries to do outside of the scope of what the user allowed won't work. Plus users can restrict it even further in privacy settings.

 

[PGrey]

Everything you wrote is wrong or very wrong

This is really constructive, maybe support your statement, with facts?
I can tell someone they're wrong all day, but wouldn't do so, without facts/evidence to back it up, it's mostly just offensive, and I'm pretty thick-skinned, particularly when it comes to forums.

I used to work on mini-drivers for testing facets of windows, granted it was mostly back in the Win7, and before, some win8, but then dating way back, to the early Windows days.

I'm reading some more about the new SecureBoot mechanism (TrustedBoot/MeasuredBoot), but I'm still not all that convinced, it seems like this fails, if you get an app/driver published. They would measure against a known-good quantity, which if installed, would potentially just verifying a driver or similar was working fine.

Provide *some facts*, as to what's in place, to prevent someone from getting an app/driver signed in this scenario.
I'm not saying this is easy, or likely, and I certainly hope it never happens, but I don't think turning a blind eye with a low-install/attack surface product is necessarily good either.

 

[PGrey]

Exactly and then on top of that MS signs the application. And even if you publish something malicious it is contained in its own virtual environment and within a randomly generated memory location. So the worst you could do is get someone's contacts if they allow you permissions. Anything the app tries to do outside of the scope of what the user allowed won't work. Plus users can restrict it even further in privacy settings.

That's if you're user-mode based. If you're a user-mode app that installs a driver, say a so-called Bluetooth filter driver, then your breadth of penetration can increase greatly.
I haven't studied the BT driver-model in W10m, so that may not be the best example, just an example.
While I realize this is an unlikely (and hopefully never an issue), I'm not convinced that it's really quite as tight as one would assume.

I agree, the new SecureBoot mechanisms (which can be compromised) make this far less likely, which is good stuff, but impossible, no.
Difficult and VERY unlikely with the attack surface/base on Windows phone, VERY unlikely, fortunately.

There was a movement afoot to sandbox all the drivers, way back, but to my knowledge this is still mostly just a great idea, with a LOT of complications involved in implementation.
Most drivers, as they stand today, are not virtualized in any way, and have full run, if they become "trusted".

 

[a5cent]

Okay, then explain *exactly* how malicious code is prevented from being published in the store?
I can publish a utility, and obtain a driver cert, and as long as it matches my "company", and meets certain guidelines, I'm allowed to publish.

In this thread we're talking about malware in the context of PHONES. Nothing else. To me it sounds like you have some Windows dev experience and expect your knowledge to translate to the WP OS, which is rarely the case.


First off, can you provide a link describing how you get a driver cert for a phone app you published to the app store?


In the context of phones this sounds very fishy to me.

 

[anthonyng]

Nobody bothered due to small or near non-existent market share.

I used to say that about macs and ios years back. People with their infected computeres kept asking me is it better than windows? There's no viruses right?

Bottom line it's true.

 

[PGrey]

In this thread we're talking about malware in the context of PHONES. Nothing else. To me it sounds like you have some Windows dev experience and expect your knowledge to translate to the WP OS, which is rarely the case.


First off, can you provide a link describing how you get a driver cert for a phone app you published to the app store?


In the context of phones this sounds very fishy to me.

Sure, this link talks about getting it signed for multiple platforms, including phone:
https://msdn.microsoft.com/windows/hardware/drivers/develop/getting-started-with-universal-drivers

I didn't sign up for an account, I don't have any current dev setups anyway, or even VS 2015. This is clearly the next step.
You're correct, I have previous dev. experience, which is definitely dated, in particular with regards to the new boot process.

I don't doubt this is hard/tricky, much more so on the phone, but do I see a complete block, well, I'm not so sure.
I don't think it's really all that interesting of a discussion anyway, beyond the academic side, given the lack of install base.
What is important though, I think, is to not dismiss this outright. If you search around on the new boot loader process, you can find lots of articles poking similar holes in it. Granted, they're mostly desktop (as per above), but some talk about the mobile possibility as well.

I actually did some test work earlier in Windows cycles, to try and prevent this type of issue, making sure certain interfaces were valid, and robust, which sort of eliminates another big chunk of "potential" in this category, but not completely. It was always a vexing problem to discuss.

I don't like it when people just say "you're a big liar", without backing things up, per one of the previous posters. That to me is just uncalled for, and unprofessional, in a forum, but I guess everyone is entitled to their "opinion".

I'm a HUGE fan of the UWP idea, a proponent since the VERY early Windows phone days, back around 2010, in 7.0, when it was first being vetted.
It's cool to see it taking off, now, sure wish it had happened 6-12 months back...

 

[PGrey]

I used to say that about macs and ios years back. People with their infected computeres kept asking me is it better than windows? There's no viruses right?

Bottom line it's true.

Yep iOS is far LESS vulnerable, partlt because of the modular kernel design, and partly because of the almost-completely-closed-very-tightly-controlled system. This doesn't make it impenetrable to things like buffer overruns, and communication driver holes, however, just far less vulnerable.

Yeah, there were never any Mac viruses...

Someone brought up the router DNS issue, where a buffer exploit was used. I don't believe this was as widespread as you hear, but it definitely makes you think about what's really a "safe" device.

 

[Pete]

As interesting as this driver discussion is, the actual capabilities of the universal driver API framework hasn't been covered. I'm willing to bet that the sandboxing that covers app development also umbrellas driver development in only allowing functionality within constrained boundaries.

I suspect that whatever thoughts you've raised have also been explored by many others. If there were a vulnerability, we'd know about it by now.

 

[PGrey]

I don't believe sandboxing of (most anyway, some things like video are "different") drivers has really ever taken place.
It's expensive, and insanely complex, given the interoperability issues. If you have a pointer, I'm definitely interested...

The exploits are just too expensive (both in terms of time and money) to use, unless the balance were different somehow. I believe this was part of making the process just that much more difficult, it made it harder for "Widgets Inc." to publish whatever they wanted, in kernel space.

 

[Pete]

I don't believe sandboxing of (most anyway, some things like video are "different") drivers has really ever taken place.
It's expensive, and insanely complex, given the interoperability issues. If you have a pointer, I'm definitely interested...

Taken from the page you linked to above

A Universal Windows driver calls only device driver interfaces (DDIs) that are part of UWP. These DDIs are marked as Universal on the corresponding MSDN reference pages.

This implicitly creates a sandbox wall around the capabilities of Universal Drivers and doesn't give unfettered access to the kernel in the same way as you could with the traditional Win 7 (and earlier) API framework. Back then, I could have all sorts of fun simply with VBScript.

I don't think that the only hurdle to create malicious code on Windows Phone is that of effort, I believe that there's more fundamental barriers in place that prevent this from happening.

You might want to look around on the XDA forums, which are more developmentally orientated than this community and will give you the hard facts.

 

[a5cent]

^ Pete summed up my own suspicions very well.
I'm certain that the hypothesized driver exploit isn't doable on WP8.1. Primarily because that sort of access isn't available. Unfortunately, I don't know enough about W10M to make the same assertion for the UWP.

If I was judge, I'd say the hypothesized driver exploit is still too fishy to be accepted as evidence by the court. ☺
Anyway, I'm happy to see more technically minded people around here, whether I (know enough to) agree with them or not .

 

[Krystianpants]

That's if you're user-mode based. If you're a user-mode app that installs a driver, say a so-called Bluetooth filter driver, then your breadth of penetration can increase greatly.
I haven't studied the BT driver-model in W10m, so that may not be the best example, just an example.
While I realize this is an unlikely (and hopefully never an issue), I'm not convinced that it's really quite as tight as one would assume.

I agree, the new SecureBoot mechanisms (which can be compromised) make this far less likely, which is good stuff, but impossible, no.
Difficult and VERY unlikely with the attack surface/base on Windows phone, VERY unlikely, fortunately.

There was a movement afoot to sandbox all the drivers, way back, but to my knowledge this is still mostly just a great idea, with a LOT of complications involved in implementation.
Most drivers, as they stand today, are not virtualized in any way, and have full run, if they become "trusted".

To update firmware which hosts a lot of the driver instructions for those stacks would require you to have a signing key from MS. If that key ever got out in public then it would be a problem. Luckily it can be revoked and have a new one generated. And sure it can be bypassed if you're skilled but you need access to the hardware directly.
On top of that a TPM is used which has a cryptoprocessor dedicated to that specific device. It can verify hardware/software integrity. It's still vulnerable no doubt. Both android/ios devices have been rooted. It's only a matter of time before the same happens to windows mobile. It's not an easy process though and takes a large amount of skill. And of course you need to have the device with you. But point is that while your phone is not rooted it will maintain security. Even android phones are not subject to a lot of different exploits unless they are rooted. Sometimes they are sure, but that's the nature of android unfortunately. It's easier to attack a fully open sourced OS and it also relies on open source libraries that aren't necessarily tightened down heavily.

Anyways, as it stands today you can't really have much done to your phone from a store app. So if you stick with that you likely won't have many issues. MS is pretty hard on security in order to have businesses invest into windows mobile.

And as far as you getting a drivers cert. It doesn't work that way. MS deals with all the drivers themselves and package them as part of the full mobile package that is installed. Regular companies don't have access to install drivers in their apps. They have a layer of access to the OS which is the API. That allows them to do what they need and is hardened down so that they don't get anymore access than that. This UWP api is also resulting in complaints from some people in the industry due to its hardened down nature. Gamers in particular are scared of not being able to mod properly as you can't do anything like with w32 which would allow you to inject things into executable code and alter how things work. MS is instead trying to build the API to allow for a modding type framework. So UWP api is still a work in progress likely till redstone 2. It will always be enhanced as new features come out, but it is far from being on par with w32.

 

[PGrey]

Taken from the page you linked to above



This implicitly creates a sandbox wall around the capabilities of Universal Drivers and doesn't give unfettered access to the kernel in the same way as you could with the traditional Win 7 (and earlier) API framework. Back then, I could have all sorts of fun simply with VBScript.

I don't think that the only hurdle to create malicious code on Windows Phone is that of effort, I believe that there's more fundamental barriers in place that prevent this from happening.

You might want to look around on the XDA forums, which are more developmentally orientated than this community and will give you the hard facts.

Actually, the Universal DDI include things like PhystoVirt and the whole works, I did a little browsing. They also include IoCtl build-outs, the whole works.
While the Universal DDI doesn't include "the world" in DDIs, it does include plenty that are free-ranging APIs, i.e. not limited to a virtual address space.
I still think the biggest hurdles are the process to get signed (this is expensive and complex now, always was, and all the loopholes are closed now), and the fact you have to write a fully-functioning driver, and even then, you have a really low target surface, for Windows phone.

No question, this was MUCH simpler back in the <=Win7 days, when, like you say, you could scribble something together relatively easy, and create your own test-cert, which just required a user saying they were okay with install.
The new boot mechanisms and such have added robustness here too, and combined with the above points, it seems really unlikely this would ever happen.

I agree though, XDA is probably a better place to have a discussion about this. I was simply responding to several who said "can't happen", and it got a bit out-of-hand, my old "you can build it, if you have the resources" mentality kicked in...

 

[PGrey]

To update firmware which hosts a lot of the driver instructions for those stacks would require you to have a signing key from MS. If that key ever got out in public then it would be a problem. Luckily it can be revoked and have a new one generated. And sure it can be bypassed if you're skilled but you need access to the hardware directly.
On top of that a TPM is used which has a cryptoprocessor dedicated to that specific device. It can verify hardware/software integrity. It's still vulnerable no doubt. Both android/ios devices have been rooted. It's only a matter of time before the same happens to windows mobile. It's not an easy process though and takes a large amount of skill. And of course you need to have the device with you. But point is that while your phone is not rooted it will maintain security. Even android phones are not subject to a lot of different exploits unless they are rooted. Sometimes they are sure, but that's the nature of android unfortunately. It's easier to attack a fully open sourced OS and it also relies on open source libraries that aren't necessarily tightened down heavily.

Anyways, as it stands today you can't really have much done to your phone from a store app. So if you stick with that you likely won't have many issues. MS is pretty hard on security in order to have businesses invest into windows mobile.

And as far as you getting a drivers cert. It doesn't work that way. MS deals with all the drivers themselves and package them as part of the full mobile package that is installed. Regular companies don't have access to install drivers in their apps. They have a layer of access to the OS which is the API. That allows them to do what they need and is hardened down so that they don't get anymore access than that. This UWP api is also resulting in complaints from some people in the industry due to its hardened down nature. Gamers in particular are scared of not being able to mod properly as you can't do anything like with w32 which would allow you to inject things into executable code and alter how things work. MS is instead trying to build the API to allow for a modding type framework. So UWP api is still a work in progress likely till redstone 2. It will always be enhanced as new features come out, but it is far from being on par with w32.

Yeah, the TPM business makes this harder, without a doubt. From my reading though, OEMs have an option to disable it, if they want, and it's dynamically disable-able as well.

On the certs, unless something has change, you can get a co-signed cert, which is trusted by MS, or at least you used to be able to, maybe that part's changed, I'm not 100% on top of all the current driver models/rules.
This was to make it possible for people to distribute their own packages, via their OEM/IHV release points, and that kind of thing.
I see utilities that are outside of the Store, for the phone, and I wonder, if they can also install a driver this way, maybe it's not possible.
I fully admit to not being a mobile developer, and certainly not current on W10m, in terms of driver trust models and the like.

This page here describes how to get your package all set up for install on mobile though, and does appear to be current:
https://msdn.microsoft.com/windows/...2459594)(TnL5HPStwNw-hti.Zs4tUoDkdnB8NuxaTA)()
Distribution for install is trickier, unless they're side-loading, covered here:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/develop/distributing-a-driver-package-win8

UWP is definitely getting restricted, but that's not the same as Universal DDI interfaces, the ones you'd use for a driver that was portable to any OS. The Universal DDI set is NOT restricted to a given virtual address space, at all, if you go look at some of the old DDIs we used to use, when writing test drivers (I was curious, so I looked up a few common ones, avoiding downloading the whole WDK).

I 100% agree, the barriers are MUCH higher, the complexity is way up there, there's the boot protection and other components in-place as well.
Is this good, you bet, I really don't want my phone getting compromised.
Is it iron-clad, well, maybe, but my old, dated, developer-sense is saying that is just really difficult now, perhaps difficult enough that it's not viable, which is almost as good as the former.

I probably carried this discussion too far, but when people started saying things like "you're just wrong" with no basis, I got a little fired up, and dug into the latest docs a bit, to see how accurate my old constructs were. Turns out, they're not that far off, but new additions have been added, and that we're "mostly safe", IMHO.

-pete

 

[PGrey]

^ Pete summed up my own suspicions very well.
I'm certain that the hypothesized driver exploit isn't doable on WP8.1. Primarily because that sort of access isn't available. Unfortunately, I don't know enough about W10M to make the same assertion for the UWP.

If I was judge, I'd say the hypothesized driver exploit is still too fishy to be accepted as evidence by the court. ☺
Anyway, I'm happy to see more technically minded people around here, whether I (know enough to) agree with them or not &#55357;&#56833;.

Could be "too fishy" the lynch-pin is *if* you could get your driver signed/installed on phone devices. It sure looks to me like it's VERY difficult on phone devices, but nothing I read said "you can't add your NDIS filter driver" to a phone, if it has merit, as part of an app. Say if I wanted to build a cell data-limiter, which people on various cellular forums are often clamoring for, to prevent their kids from nuking their cell limits (me, I just talk to mine, and have the ultimate, "we can always just turn off data if you prefer" clause, but whatever).

I enjoy the technical side of this, as it was my roots, in the Win group, but I'm long out of the loop (all tech PM now, with maybe an enlistment of the code my group is working on, at-best), haven't written any real code, certainly not an kernel-level code for a really, really long time now. But, a lot of the kernel and constructs are the much the same, with adjustments/tweaks, having "grown up" from the WinNT days. Dave Cutler and his "crew" were a insanely smart bunch, and a lot of those old interfaces persist, to some degree.

 

[Mad Cabbie]

Anyone got a length of rope and a chair?? ;-)

 

[PGrey]

Anyone got a length of rope and a chair?? ;-)

Yeah, I already said I knew the conversation had gotten a bit long-winded, no need...
Probably if a couple of posters hadn't said "you're just wrong" with no backup data, I would've not gone off the deep-end.

I'll go back to quietly awaiting my firmware update now, and fiddling with my phone accordingly, and not incite "malware" posters ;-]

-pete