Recap of BYOD Risks

By Kunal Garg.

Bring Your Own Device (BYOD) has been a hot topic over the last two years as organizations begin to permit employees to bring personally owned mobile devices (such as laptops, tablets, and smart phones) to their workplace, and let them use those devices to access the corporate network and sensitive information on it.

Businesses usually get some advantage with this program, as the cost for acquiring device is already born by the user/employee which may save companies a lot of money. Other benefits are increased productivity efficiency and the ability to work remotely.

Risks and vulnerabilities also increase when end user devices come in picture on an already hardened and secure network. Company has control over the issued corporate owned devices and has necessary security mechanisms in place. Implementing security technologies and defining an acceptable use policy for user owned device is not an easy task. It is pretty hard for an “IT guy” to tell the end user what to do and what not to do on their swanky phones, tablets and laptops.

Some of the common risks associated with BYOD program:

1. Jail breaking/Rooting - Many users’ jail break /root there phone to have admin privileges and rights on the phone. These custom jail break apps are just install and run, and it’s fairly easy for novice user to root the device. This process however beats the in-built security mechanisms implemented in devices and also opens the attack surface.
2. Mobile Accessibility - Mobile devices can move far beyond the boundaries of the corporate network. Open Wireless networks available in coffee shops, airports etc. gives attacker the opportunity to directly communicate with the corporate owned entity, perform Man in the middle attack, and sniff the network traffic for sensitive data.
3. Personal/Corporate Separation - A personal device is used for far different purposes, and far more often then a corporate device. This places the security decision in the user more than ever. A malicious application may have far greater consequences when installed on a corporate device. For instance, granting excessive permissions to a mobile application may seem harmless to a user but may result in data leakage.
4. Lost or stolen devices - Lost or stolen devices tend to possess serious security risk, as a lot of sensitive information is on the device. Devices should have solution of remote wipe/clean.
5. Employee Resignation/Termination - If the employee is let go, or leaves the company, recovering and deleting company data can be a problem. There should be a policy in place that governs how that data will be retrieved from the personal laptop and/or smartphone.
6. Device Sharing - Mobile devices are more likely to be occasionally shared, potentially putting corporate data at risk. A person with malicious intent can read sensitive information on enterprise applications. Re-authentication upon each access and two factor authentication should be implemented.

What risks do you see around BYOD? Let us know in the comments below!

Heartbleed Recap and Testing

By Mateo Martinez and Melissa Augustine.

CVE-2014-0160 also known as the "Heartbleed Bug", is a serious vulnerability in OpenSSL, one of the most widely used cryptographic libraries. This bug has been present in OpenSSL since March 14, 2012 with the release of version 1.0.1 and specifically affects OpenSSL's implementation of the TLS/DTLS protocols.

To summarize, Heartbleed allows anyone to read the memory of a system running services that use OpenSSL for TLS/DTLS.

Why HeartBleed?

TLS/DTLS leverage “hearbeat”, or “keep alive” messages once a session is established to let hosts know that a connection is still needed and active. Here is an example of a normal heartbeat that occurs after the initial SSL connection has already taken place.

OpenSSL implemented this heartbeat in a way that allowed the user to TELL the server how much data it wanted to echo back. A client can request up to 64k of memory per heartbeat. Stored within the memory can be anything processed by the service, including usernames, passwords, and private keys.

Affected Versions and Recommendations

OpenSSL versions 1.0.1 through 1.0.1f are vulnerable and the fix was implemented in version 1.0.1g. The blanket recommendation is to apply the patch and change passwords. It is important as a user to ensure whatever application you are using has already implemented the patch before changing your passwords; otherwise your new password may still be susceptible to attack.

Prior Detection

How do you tell if someone has used the attack against you in the past? Well, that’s the tricky part - this bug was unknown for a long time, so prior to its release no sensors or products would detect it occuring. If you maintain network captures for your network, you may be able to query that data and look for a signature.. but there is nothing left on the server side that would be an indicator it was being exploited.

Now that the attack has been publicly disclosed, there are now a multitude of detection mechanisms in place to alert administrators of a Heartbleed attack (including Snort, Tripwire, and Honeypot scripts) .

Testing

There are a ton of ways to test for Heartbleed - McAfee has released a Heartbleed Checker tool, there is a metasploit module, and even a nmap nse script. We'll cover the nmap script here.

Using NMAP

Checking HeartBleed with NMAP is a painless process. Firstly you'll need to download the script and place it in the default NSE folder (/usr/share/nmap/scripts)

Next download the TLS library to the nselib folder:

Now make sure nmap has updated it script db:

 root@kali:~# nmap --script-updatedb

And you're ready to roll! To test a specific URL you can run:

 root@kali:~# nmap -vv -p 443 --script ssl-heartbleed www.somesite.com -oN somesite_outputfile

To test a range of hosts you can use:

 root@kali:~# nmap -vv -p 443 --script ssl-heartbleed 192.168.1.0/24 -oN subnet_outputfile

And to test multiple ports, just run:

 root@kali:~# nmap -sV -p 443,8443,6443 --script=ssl-heartbleed.nse 192.168.1.1

Secure Usage of Android Webview:

By Naveen Rudrappa

The WebView class is one of the most powerful classes and it renders web pages like a normal browser. Applications can interact with WebView by adding a hook, monitoring changes being made, add JavaScript, etc. Even though this seems like a great feature; it brings in security loopholes if not used with caution. Since WebView can be customized, it creates the opportunity to break out of the sandbox and bypass the same origin policy.

WebView allows sandbox bypass in two different scenarios:

1. JavaScript can invoke Java code.
2. Java code can invoke JavaScript.

Sample code to Invoke Java from JavaScript:

 wv.addJavascriptInterface(new FileUtils(), "file");
< script> 
filename = '/data/data/com.Foudnstone/data.txt';
file.write(filename, data, false);
< /script> 

Sample code to Invoke JavaScript from Java:

 String javascr = "javascript: var newscript=document.createElement(\"script\");";
javascr += "newscript.src=\"http://www.foundstone.com\";";
javascr += "document.body.appendChild(newscript);";
myWebView.loadUrl(javascr);

Another way to support sandboxing is to implement addJavascriptInterface. However any class declared using addJavascriptInterface allows for commands to be run on android device from JavaScript, leading to complete compromise. Hence implementing addJavascriptInterface is also not safe.

Hence to implement secure usage of WebView follow the below mentioned solutions:

• Compile application against Android API level equal or more than 17. This API forces developer to add @JavascriptInterface to any method that is to be exposed to JavaScript. This also prevents access to operating system commands (via java.lang.Runtime).
• Disable Support for JavaScript. If there is no reason to support JavaScript within the WebView, then it should be disabled. The Android WebSettings class can be used to disable support for JavaScript via the public method:

   setJavaScriptEnabled.webview = new WebView(this); webview.getSettings().setJavaScriptEnabled(false);
  

  
  
  
• Send all traffic over SSL. Any traffic in clear is easy to sniff and manipulate using a Man-in-The-Middle attack. Thus an hacker cannot inject script via MITM and can not break sandbox of webview.
• To avoid security issues from the WebView, always restrict users to the application domain using code as below which prevents WebView security issues. By restricting user to known domain we are secure from Javascript being loaded from untrusted websites.

   WebViewclient wvclient = New WebViewClient() {
  // override the "shouldOverrideUrlLoading" hook.
  public boolean shouldOverrideUrlLoading(WebView view,String url){
  if(!url.startsWith("http://clientlocation.com")){
  Intent i = new Intent("Android,intent.action.VIEW",Uri.parse(url));
  startActivity(i);
  // override the "onPageFinished" hook.
  public void onPageFinished(WebView view, String url) { ...}
  }
  webView.setWebViewClient(wvclient);
  // override the "onPageFinished" hook.
  public void onPageFinished(WebView view, String url) { ...}
  }
  webView.setWebViewClient(wvclient);
  

  
  
  

Application Whitelisting Programs, WinXP EoS, and HIPAA's Security Rule

By The Foundstone Strategic Services Team.

The United States Department of Health and Human Services (HHS) has stated that the “Security Rule does not specify minimum requirements for personal computer operating systems”. Microsoft’s own Windows XP enterprise end of support website points readers directly to the Health and Human Services (HHS) Security Rule guidance on operating system requirements for the personal computer systems used by a covered entity. The HHS guidance covers a situation such as Windows XP End of Support(EoS) when it states that:

"any known security vulnerabilities of an operating system should be considered in the covered entity’s risk analysis (e.g., does an operating system include known vulnerabilities for which a security patch is unavailable, e.g., because the operating system is no longer supported by its manufacturer).”

HHS guidance explicitly addresses the security compliance that an operating system provides when it states:

“the security capabilities of the operating system may be used to comply with technical safeguards standards and implementation specifications such as audit controls, unique user identification, integrity, person or entity authentication, or transmission security.”

It is clear that an unsupported operating system will need to have significant technical safeguards deployed and configured properly to reduce the risk of exploitation of the unsupported operating system. Application whitelisting programs used to be considered an optional technical security control, but as the nature of networks and applications changed, application whitelisting programs moved past being a “best practice” years ago. It is now considered both a basic and standard security control. When configured properly, these programs can arguably be the strongest component of operating system defense in depth. It can protect against the deliberate or inadvertent exploitation of operating system vulnerabilities, regardless of whether the workstation activity is performed by authorized users, unauthorized users, or malware. Application whitelisting programs have been identified as the first of the five “Quick Wins” in the Top 20 Security Controls – these are the sub-controls that have the most immediate impact on preventing attacks.

These programs offer a range of features that significantly reduces the attack surfaces that threats are actively attempting to exploit. Risk is reduced because there is much less opportunity to deliberately or unintentionally exploit potential weak spots or vulnerabilities. The abilities of application white-listing programs to limit, disable, or restrict access makes it a significant part of defense in depth best practices for all operating systems, including Windows XP as it becomes unsupported.

We'll focus on the feature set of McAfee's Application Control since this is most available to us, but most other feature rich whitelisting applications should contain similar functionality. If you're unsure if all of these items are addressed with the particular program you're evaluating, reach out to the vendor or conduct your own analysis

Application Control

Achieving compliance with the Security Rule while continuing to use Windows XP will involve documenting your risk analysis and using reasonable and appropriate technical safeguards such as application white listing to reduce the likelihood that threats can exploit vulnerabilities.

Human Threats Addressed:

• Abuse of Information System
• Abuse of Privileges
• Abuse of Resources
• Damage to ePHI or Business Information
• Destruction of ePHI or Business Information
• Theft of ePHI or Business Information
• Theft of Financial Assets

Threat Agents:

• Reckless Insiders
• Untrained Insiders
• Reckless Information Partner
• Untrained Information Partner
• Reckless Line of Business
• Untrained Line of Business
• Disgruntled Insider
• Disgruntled Information Partner
• 3rd Party Threats
• Organized Crime

Application whitelisting programs also directly supports you if you will be the recipient of a HIPAA Audit Protocol assessment pursuant to the HITECH Act audit mandate. It can specifically enforce or support compliance for components in the Audit Protocol assessment of;

• Information Access Management §164.308(a)(4)
• Workstation Use (§164.310(b))
• Access Control requirement “to allow access only to those persons or software programs that have been granted access rights”
• Audit Control (§164.312(b))

For environments where there is a need to comply with the Centers for Medicare & Medicaid Services (CMS) requirements which involve NIST 800-53 standards, Application whitelisting programs support meeting these NIST control family standards;

• Access Control (AC) - This control family includes mechanisms used to designate who or what is to have access to a specific resource and the type of transactions and functions that are permitted.
• Configuration Management (CM) - This control family aims to address the activities that present a risk of integration failure due to component change. This includes change control processes and asset management.
• Maintenance (MA) - This control family addresses the requirement that trusted systems within the environment retain their trustworthiness over time. Key elements include patch management, system builds, and hardening processes
• System and Information Integrity (SI) – The controls in this family are used to protect data from accidental or malicious alteration or destruction and to provide assurance to the user the information meets expectations about its quality and integrity. Additionally, this family covers various aspects of flaw remediation.

CMS has also referenced the Top 20 Critical Security Controls (now maintained by The Council on CyberSecurity). The latest version of the Top 20 (Critical Controls Version 5.0) continues identifying application whitelisting as the first of five “Quick Wins”; these are the sub-controls that have the most immediate impact on preventing attacks.

Enjoy!



*Image above was borrowed from here