Countermeasure for BYOD Threats – Real World Scenario


One year ago I was speaking at Microsoft CSO (Chief Security Officer) Council – Fall 2013 in Redmond, during that opportunity I also had a chance to record an interview with Tim Rains where we discussed some results from the Security Intelligence Report V15. Almost one year later, the main subject of that presentation keep growing and making news: BYOD. Today I will go over one real world scenario that happened to me and after deeper investigation I could conclude that the target of that attack was not a PC with Windows, but a mobile device with Android. After that I will go over a countermeasure for this scenario and how companies could mitigate issues like in cased it happened in a BYOD scenario.

It starts with a simple Phishing E-Mail

I received an interesting e-mail from a bank (in Brazil) in which I don’t have an account, the e-mail was asking me to update my password. I also hover the mouse over the URL that was there, where the instructions said to “click” in order to access the web site and noticed that the real URL (the one that shows in the status bar in the bottom of the IE window) was pointing to a completely different place, not even related to the bank.

Mobile Threat Alert: mobile users won’t be able to detect this since they don’t hover over the link to see the URL; they just tap with their fingers.

Clearly it was a phishing and I decided follow through in my isolated test environment. My client machine was behind my Forefront TMG box (yes, I’m still using it and its still rocking) and once I click on the link I was able to see a very interesting behavior, let’s start for the image below:

image

This page is not using HTTPS (which is pretty much the default or all online banking) and the URL address doesn’t match the official bank URL. Again, clearly (to me) a phishing e-mail.

Mobile Threat Alert: mobile users might not be pay attention to those details for many reasons, such as: small screen, hurry to get things done and lack security awareness about those types of attacks.

I went back to my TMG box and noticed that a redirect was done as shown below:

image

Notice the HTTP 302 that sends me to a different location (although I’m hiding the domain, you can see that the rest of the URL is different):

image

This raised a flag to me, because when I query the domain name, it was sending me to a Russia web site (wait, a fake Brazilian bank sending me to Russia…hum). So I decided to download this function.php file by using WGET for Windows. Here it is the result:

image

Notice that 302 there again and it actually downloads an index.html file that has another call for another site, which is located in Ukraine and it tries to download an APK File (Android file) that has a suspicious ID called “bots” (that sounds promising):

image

This is the clear indication that the entire rationale behind the phishing e-mail followed by a download of an APK file was to infect an Android device. I went further and extracted this APK file to review some of the details and not surprising the DEX File was loading over the HTTP session, which is a known type of attack (you can read a great explanation about this in a paper presented at Black Hat 2014, you can download it here). When I tried to install this simple App in my Android (running on my Windows 8.1 Hyper-V), I got this notification:

image

Notice that this app (which I have no idea what it does) is requesting access to many capabilities that are built in on the phone. I did allow and I installed the app, however once I tried to launch it didn’t work, because some of the files that were downloaded initially (like in the first connection) were done in my Windows VM, therefore this Android VM was not able to find those file and failed to launch. But, I didn’t need more than that to understand what was going on.

BYOD Countermeasures

This is a scenario that is very common and as I said, it can start with only a simple phishing email that the end user in a moment of “multitasking” on the phone might just follow the instructions. That’s where the MDM solution for BYOD plays a big role. By leveraging capabilities available on Microsoft Intune in combination with System Center Configuration Manager you can manage Android devices and hardening some settings. You can deploy compliance settings for BYOD devices with Android to hardening the following settings:

 

Device Setting Group

Settings

Values

iOS (See below for settings introduced by the iOS 7 settings extension)

Browser

Default browser

Allowed/Prohibited

Yes

Browser

Autofill

Allowed/Prohibited

Yes

Browser

Active scripting

Allowed/Prohibited

Yes

Browser

Pop-ups

Allowed/Prohibited

Yes

Browser

Fraud warning

Allowed/Prohibited

Yes

Browser

Cookies

Allowed/Prohibited

Yes

Cloud

Encrypted backup

Allowed/Prohibited

Yes

Cloud

Document synchronization

Allowed/Prohibited

Yes

Cloud

Photo synchronization

Allowed/Prohibited

Yes

Cloud

Cloud backup

Allowed/Prohibited

Yes

Content Rating

Explicit Content in media store

Allowed/Prohibited

Yes

Content Rating

Ratings Region

Country of choice

Yes

Content Rating

Movie Rating

Rating

Yes

Content Rating

TV Show Rating

Rating

Yes

Content Rating

App Rating

Rating

Yes

Device

Voice Dialing

Allowed/Prohibited

Yes

Device

Voice Assistant

Allowed/Prohibited

Yes

Device

Voice Assistant while Locked

Allowed/Prohibited

Yes

Device

Screen Capture

Enabled/Disabled

Yes

Device

Video Conferencing

Enabled/Disabled

Yes

Device

Add Game Center friends

Allowed/Prohibited

Yes

Device

Multiplayer Gaming

Allowed/Prohibited

Yes

Device

Personal wallet software While Locked

Allowed/Prohibited

Yes

Device

Diagnostic data Submission

Enabled/Disabled

Yes

Password

Require password settings on mobile devices

Required

Yes

Password

Password complexity

PIN, Strong

Yes

Password

Idle time before mobile device is locked (minutes)

1 minute – 12 hours

Yes

Password

Minimum password length (characters)

4-18

Yes

Password

Number of passwords remembered

0-50

Yes

Password

Password expiration in days

1-365

Yes

Password

Number of failed logon attempts before device is wiped

0-100

Yes

Roaming

Allow Voice Roaming

Allowed/Prohibited

Yes

Roaming

Allow Data Roaming

Allowed/Prohibited

Yes

Security

Camera

Allowed/Prohibited

Yes

Security

Allow app installation

Allowed/Prohibited

Yes

Store

Application Store

Allowed/Prohibited

Yes

Store

Force Application Store Password

Enabled/Disabled

Yes, this setting applies to iTunes only

Store

In App Purchases

Allowed/Prohibited

Yes

System Security

User to accept untrusted TLS certificates

Allowed/Prohibited

Yes

To see the entire table go to http://technet.microsoft.com/en-us/library/dn376523.aspx

When you integrate Intune with System Center you can create custom polices for devices that are coming from the cloud (they were enrolled using Intune) and apply those policies just for these devices by using groups. By hardening the system you will reduce the probability that attacks of this nature take place in BYOD scenarios, but this is not the ultimate answer since BYOD is a very broad subject, remember also to:

  • Have a great designing strategy to embrace BYOD (read our BYOD Design Considerations Guide for that)
  • Security Awareness Training for your Employees must include Mobile Security topic, this is a must have nowadays
  • Monitoring and auditing your resources. If you are using Enterprise Mobility Suite to manage your company-owned devices and user-owned devices you will have access Azure AD Premium Reports, which can give you great details about user’s activity, including suspicious authentication patterns.

That’s all for today folks, stay safe, plan for BYOD and securely embrace mobility!

Comments (0)

Skip to main content