VMware Workspace ONE Community
mibir
Contributor
Contributor

iOS 13 Devices Marked as Compromised

Hey All,

Curious if anyone has any folks already upgrading to iOS 13 and if they are seeing any issues with devices being marked as compromised. We have 9 developers that have upgraded for testing and 3 of the 9 have been marked as compromised after upgrading but 6 of them seem to be fine. I'm guessing something is going a little weird during the update process that confuses Intelligent Hub but was curious if anyone else is seeing odd behavior.
Labels (1)
100 Replies
GuenterGruber
Contributor
Contributor

Thomas B. I´m not sure if the workaround will help in my configuration. We do not use the boxer, so it´s rather the hub-app that triggers the compromised status.
What I also found out was that the status switched on some devices more than one time from true to false and back to true - but could not find any reason for that change. Some times it helps to start the hub and force a sync, somtimes a restart of the device helps, and on other devices nothing will help...
So at this time I will wait for a new hub-(or iOS) version, the compromised-status is a ' beauty mistake'  without impact.

Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

Thomas B/Adam B - Do you have Boxer configured with per-app VPN? Trying to understand the correlation between Boxer and VMware Tunnel.

Guenter G - According to AirWatch support, Hub is the only app that supposedly contains the ' fix'  to the SDK incompatibility issue. Assuming what they have told me is correct, waiting for a new version of Hub isn't going to help you.
Reply
0 Kudos
ThomasBeckerTho
Enthusiast
Enthusiast

Mark S.
Yes, we use Boxer as per-app VPN with Tunnel. The mail settings are in the Boxer app configuration. We also do not use the SEG.
Reply
0 Kudos
GuenterGruber
Contributor
Contributor

Mark S - in this case my fist question is: ' what have they fixed?' . Every day the number of compromised devices on my dashboard increases. The good message is, this is currently the only negativ impact.
The next question is: why are not all of my ~16.000 devices affected? They all using also the last HUB-Version...


With the beta version of iOS 13.0, nothing like this has been noticed yet, only since the first official version was available the compromised devices appeared (whit the ' on-off'  effects I wrote in my last message)...

Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

Guenter G - I'm just relaying the message. Honestly, given their lack of transparency regarding the matter, I don't think they even know what is causing it let alone have a fix for it.

Mark
Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

We are still being plagued by this issue, despite all the AirWatch apps supposedly now containing the fix for this issue. With a recent campaign to get all of our users updated to iOS 13.3, we've seen a considerable increase in the number of devices being detected as compromised. Now the fix seems to be to uninstall/reinstall the Hub app, despite it already being on the latest version.

Anyone else seeing this?
Reply
0 Kudos
Stansfield
Enthusiast
Enthusiast

We gave up and stopped having it do anything a while back sometimes just re-opening the apps will clear compromised but not always
Reply
0 Kudos
alldaymcrae
Contributor
Contributor

Not the exact problem and it depends on your setup but if you're using the VMware tunnel and Boxer they require the Hub app to be on the device and and on latest version. There is a direct correlation with Boxer and Hub app though if you have that setup. In regards to Compromised devices that has only happened to one user over the last month but that user didn't have the hub app installed. Since making sure that its installed everywhere and then also we turned off everything in regards to compliance we haven't seen the issue for about 2 weeks now   We don't use VMware Tunnel so according to the support tech  we don't need to worry about the Hub app but I'm currently work with there support to get it working correctly after enrollment because there is another bug with it not allowing a user to login after enrollment. It works fine to enroll but after enrollment it doesn't authenticate using the default SDK profile setup. Content locker uses that currently and it works fine.
Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

Jeremy - We use VMware Tunnel and Boxer, but we don't have Boxer configured to use Tunnel (its not enabled for per-app VPN). All AirWatch apps are up to date when these false-positive detections take place.
Reply
0 Kudos
Stansfield
Enthusiast
Enthusiast

Has anyone had trouble with lost mode randomly enabled by the system (shows as by sysadmin in logs) support says we are the only ones it seems to be linked with an app issue even though all apps are updated and compromised detection and app passcodes are turned off it acts like the passcode trips while being off?  It usually marks the device as compromised so I thought it might be linked with this.  We do not have ssl pinning enabled (not sure if that has anything to do with anything but it might affect apps behavior)
Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

Do you have the devices set to Enterprise Wipe when compromised? Lost Mode is enabled when a device is Enterprise Wiped as a result of being compromised.
Reply
0 Kudos
Stansfield
Enthusiast
Enthusiast

We have all parts of compromised detection turned off and devices are not enterprise wiping so we are able to go back in and turn lost mode back off, it actually immediately tripped again when we tried to gather HUB logs once and had to be turned off again
Reply
0 Kudos
jpjp1
Contributor
Contributor

following this as we see devices are being email wiped with boxer randomly to at least 4 people . not even to both of their devices. it was 2 ipads yesterday.
Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

Over the last month or so, we've seen an increase once again in the number of devices being detected as compromised. In this latest round, the devices are being detected as compromised, and in most cases, going back to being compliant within a minute or two. The users aren't doing anything to rectify it, because at that point, they don't even know their device has been detected as compromised (and I've followed-up with some of them).

I think I've put in at least 4 tickets related to this never-ending problem. The last one I created, which was back at the beginning of the year, is still open, and they just responded that the issue is fixed in Hub 20.05. But they've told me similar things in the past about new versions of their apps, and the problem still happened even with the "fixed" apps installed.

Our security team is hesitant to disable Compromise Detection, but it seems to be more trouble than its worth. Don't think we've ever actually detected a real jailbroken device in over 4 years.

Reply
0 Kudos
AntonThirifays
Enthusiast
Enthusiast

Hi,

just discovering this thread as we've been suffering from this since introduction of the over-the-air compliance app check from Boxer.

Same as you, devices are marked as being compromised then in a matter of seconds / minutes / hours, the device is marked as Compliant again.

We had more or less same answers from ticket support at VMware and issue has been escalated for resolution. Waiting for a feedback now.

In our case, support asked if the following URLs are accessible from our devices.

api.na1.region.data.vmwservices.com

discovery.awmdm.com

signing.awmdm.com

The last two are mentioned in the network prerequisites as optional and the first one is not listed. Also, it seems that these URLs must be accessible from the device themselves, which is the case  for us as we do not restrict connectivity on our devices.

Given the URLs are mentioned as optional, we have no plans of opening it up from our DS / CN servers.

Final info received from the auto communications from VMWare is the following :

https://kb.vmware.com/s/article/79668?lang=en_US

From the KB it relates to 20.05 version, we're currently on 19.07 , not using tunnel and Boxer has a specific SDK profile attached to it.

Reply
0 Kudos
chengtmskcc
Expert
Expert

Check out the below and see if it helps with your issue.

ESC-22684: iOS devices incorrectly marked compromised after updating to VMware Workspace ONE Intelligent Hub 20.05

View the article https://kb.vmware.com/s/article/79668?lang=en_US

Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

What an absolute joke. Hub 20.05 was supposed to resolve the false positive compromised device issue, and now it also suffers from the same problem.

Reply
0 Kudos
MarkSchwantje
Enthusiast
Enthusiast

In our case, support asked if the following URLs are accessible from our devices.

api.na1.region.data.vmwservices.com

discovery.awmdm.com

signing.awmdm.com

The last two are mentioned in the network prerequisites as optional and the first one is not listed. Also, it seems that these URLs must be accessible from the device themselves, which is the case  for us as we do not restrict connectivity on our devices.

Given the URLs are mentioned as optional, we have no plans of opening it up from our DS / CN servers.

We were asked the same months ago. We've allowed access to those URLs, and it made no difference. Plus, with COVID-19, most of the workforce is working remotely, so they wouldn't be impacted by any firewall rules.

Reply
0 Kudos
chengtmskcc
Expert
Expert

This KB has been updated.

[Resolved] ISDK-174103: iOS devices incorrectly marked compromised after updating to VMware Workspace ONE Intelligent Hub 20.05 (79668)

https://kb.vmware.com/s/article/79668?lang=en_US

Reply
0 Kudos
callegrafi
Enthusiast
Enthusiast

Have anyone else noticed an increase on the number of compromised devices in the past 1-2 weeks?

We are on cn763 and the latest 20.8.0.6 release. The compromised devices have the latest Hub app, and after we make a re-evaluation they are marked as compliant.

Its not a big issue, but it is annoying!

Reply
0 Kudos