McAfee Mobile Security 4.5 for Android is here!

Intel Security just launched the latest version of our award-winning Android app–McAfee Mobile Security (MMS). MMS has evolved beyond providing AV protection to provide performance boosting and Android Wear features. We are proud to arm our users with these new powerful tools for optimized device performance to aid in users’ eternal struggle to gain longer battery life, more power, speed, and storage on their Android smartphones and tablets.

As the number and variety of devices in our lives increases, so does the number of threats and potential risks to our privacy. By using wearable devices we gain convenience and flexibility but open ourselves to a variety of threats, such as identity theft, insurance fraud, stalking, and many others. To address this emerging vulnerability, MMS has introduced Android Wear watch support, enabling users to stay safe and productive even when they are on the go. You can prevent loss, stay on top of mobile threats and boost your mobile device performance–all done straight from your smart watch.

Get it free here and let us know what you think!


Features include:

  • Intel Device Protection Technology. Built into the Android OS on Intel devices, this works to proactively block malware delivered through malicious apps and websites, while also conserving battery power.
  • Privacy. Deep app inspection provides a thorough crosscheck of all of your apps and informs of potential privacy violations. PIN protect your apps and create up to three user profiles.
  • Wi-Fi Protection. Alerts of non-secured Wi-Fi connections and automatically disconnects the device if it detects someone is attempting to hack into your connection in order to send your emails, keystrokes and other information to a separate server, known as ARP spoofing.
  • Web Protection. Blocks users from visiting or opening phishing sites and browser exploits in texts (SMS) and multi-media messages, emails, QR codes and social networking posts.
  • CaptureCam. Takes a picture and captures your phone’s location when there are multiple incorrect attempts to unlock your device, while your phone is on. Images and location are sent directly to your account.
  • Remote Locate, Lock, Wipe and Alarm. In the event your device is lost or stolen, use the remote lock and wipe feature from the McAfee Mobile Security management portal, or via text message from another phone, to ensure that none of your private data falls into the wrong hands.
  • NEW! Get the Most out of your Device. Add more time to your battery life when you need it most. Clean up your device’s memory to make it run faster and longer. Optimize your internal storage space to fit more apps and files.
  • NEW! Protect your mobile data plan. Never go over your limit again– monitor your usage, get threshold alerts, and bust data-hogging apps.
  • NEW! Pair your Android Wear. Never miss a security issue or leave your smartphone or tablet behind. Take actions straight from your Android Wear watch to find and secure your mobile device, fix critical issues and extend battery on your phone or tablet.
  • NEW! Easy access. Quickly boost your device and fix issues with just one tap–straight from your Home Screen Widget.

“ASP.NET MVC: Audit Logging”

Guest Editor: Today’s post is from Taras Kholopkin. Taras is a Solutions Architect at SoftServe, Inc. In this post, Taras will take a look at creating an audit logging action filter in the ASP.NET MVC framework.

Audit logging is a critical step for adding security to your applications. Often times, audit logs are used to trace an attacker’s steps, provide evidence in legal proceedings, and used to detect and prevent attacks as they are occurring. If you’re not convinced yet, many regulatory compliance laws, such as HIPAA, also require security-specific audit logs to be kept. With that said, let’s take a look at some high-level things to consider as you build out your audit logging functionality.

Events to Log:
The first step is deciding which events require logging. While regulatory compliance laws, such as HIPAA and PCI, may specify exactly which actions should be logged, each application is different. Here are some general actions to consider logging in your applications:

  • Administrative actions, such as adding, editing, and deleting user accounts / permissions.
  • Authentication attempts
  • Authorized and unauthorized access attempts
  • Reading or writing to sensitive information, such as HIPAA, PCI, encryption keys, authentication tokens, API keys, etc.
  • Validation failures that could indicate an attack against the application

Details to Log:
Each audit log entry must provide enough information to identify the user and their action in the application. The following details provide some details to consider:

  • Timestamp identifying when was an operation/action performed?
  • Who performed the action.? This is often achieved with a unique user identifier, session token hash value, and source IP address.
  • What operation/action was performed? Include the URL, action / method, and action result.
  • Which record(s) were impacted?
  • What values were changed?
  • Determine an event severity level to assist the operations team with incident response

Threshold Monitoring
In addition to the above, it is also helpful to monitor the application for unusual activity. Capturing high volumes of requests beyond normal usage can help detect automated attacks, such as password guessing, SQL injection, or access control attempts. Blocking IP addresses performing unusual activity and notifying the operations team will go a long way towards incident detection and response.

Creating an Audit Logging Action Filter
Now that we know what to do, let’s discuss how using ASP.NET MVC. The framework provides a centralized feature, known as Action Filters, which can be used to implement audit logging in your applications. ASP.NET Action Filters are custom classes that provide both declarative and programmatic means to add pre-action and post-action behavior to controller action methods. More information about Action Filters may be found here.

Let’s create an example action filter and apply it to the AccountController.Login() and HomeController.Contact() methods from the SecureWebApp project that was described in the previous article ASP.NET MVC: Data Validation Techniques.


First, create a new class called AuditLogActionFilter.cs, as shown in the following code snippet:

using System.Linq; using System.Web; using System.Web.Mvc; using System.Web.Routing; namespace SecureWebApp.Audit { public class AuditLogActionFilter : ActionFilterAttribute { public string ActionType { get; set; } public override void OnActionExecuting(ActionExecutingContext filterContext) { // Retrieve the information we need to log string routeInfo = GetRouteData(filterContext.RouteData); string user = filterContext.HttpContext.User.Identity.Name; // Write the information to “Audit Log” Debug.WriteLine(String.Format(“ActionExecuting – {0} ActionType: {1}; User:{2}” , routeInfo, ActionType, user), “Audit Log”); base.OnActionExecuting(filterContext); } public override void OnActionExecuted(ActionExecutedContext filterContext) { // Retrieve the information we need to log string routeInfo = GetRouteData(filterContext.RouteData); bool isActionSucceeded = filterContext.Exception == null; string user = filterContext.HttpContext.User.Identity.Name; // Write the information to “Audit Log” Debug.WriteLine(String.Format(“ActionExecuted – {0} ActionType: {1}; Executed successfully:{2}; User:{3}” , routeInfo, ActionType, isActionSucceeded, user), “Audit Log”); base.OnActionExecuted(filterContext); } private string GetRouteData(RouteData routeData) { var controller = routeData.Values[“controller”]; var action = routeData.Values[“action”]; return String.Format(“Controller:{0}; Action:{1};”, controller, action); } } }

The newly created custom action filter AuditLogActionFilter overrides OnActionExecuting() and OnActionExecuted() methods to write audit information to debug output window (for testing purposes). In a real scenario, use a logging framework (e.g. nLog, log4net, etc.) to write the details to a secure audit logging repository.

It’s very easy to apply the logging filter to the Login() method using our new annotation. With just one line of code, add the AuditLogActionFilter with a custom ActionType argument.
[HttpPost] [AuditLogActionFilter(ActionType=”UserLogIn”)] [AllowAnonymous] [ValidateAntiForgeryToken] public async Task Login(LoginViewModel model, string returnUrl) {

And to the Contact() method:
[AuditLogActionFilter(ActionType=”AccessContactInfo”)] public ActionResult Contact() {

The ActionType parameter is just an example showing that it’s possible to pass data into the action filter. In this particular case, the ActionType identifies the action being taken for the audit log. Once the value is passed to the action filter, any logic can be added to handle special cases.

When debugging the application, logging in and visiting the contact page cause the following lines to be written to the console output.
Audit Log: ActionExecuting – Controller:Account; Action:Login; ActionType: UserLogIn; User: Audit Log: ActionExecuted – Controller:Account; Action:Login; ActionType: UserLogIn; Executed successfully:True; User: Audit Log: ActionExecuting – Controller:Home; Action:Contact; ActionType: AccessContactInfo; Audit Log: ActionExecuted – Controller:Home; Action:Contact; ActionType: AccessContactInfo; Executed successfully:True;

This shows how easy it is to create a custom-logging filter and apply it to important security-specific actions in your applications.

To learn more about securing your .NET applications, sign up for DEV544: Secure Coding in .NET!

About the author
Taras Kholopkin is a Solutions Architect at SoftServe, and a frequent contributor to the SoftServe United blog. Taras has worked more than nine years in the industry, including extensive experience within the US IT Market. He is responsible for software architectural design and development of Enterprise and SaaS Solutions (including Healthcare Solutions).

Your mobile apps could be spying on you and telling secrets!

I am sharing this article, written by Shelly Tzoumas – Thanks, Shelly!

How close are relentless cyber criminals to hacking your mobile device—really? Security reports indicate 1 in 5 Android apps contain malware. What do you need to know? To find out, Shelly sat down with Alex Hinchliffe, Mobile Malware Research Manager at Intel Security, who explained the risk and provided five valuable mobile safety tips.

“Your everyday tasks may be the most revealing,” explains Hinchliffe. “Despite a recent rise in ransomware malware, today’s biggest mobile threat is data leakage from app ad libraries and other privacy-invasive apps.”

Tip 1:  Skip the ‘free’ version of apps and don’t download apps that share too much

We all, by nature, want to get something for free. Usually, when you download the “free” version of an app, you accept in-app advertisements. The ads are a little annoying, but the worrisome part is happening behind the scenes. The app has permissions to collect data from your mobile device that it doesn’t need.

“Typically, ad libraries are tracking your tasks, what network you are using, and collecting your account information,” says Hinchliffe. The data enables retailers to target you with coupons and promotions. “You can avoid over-sharing by reading the app reviews and permissions information,” advises Hinchliffe. “We are finding only a handful of ad libraries associated with malware, so the risk here is primarily to your privacy.”

Tip 2:  Install a good security software to guide you through confusing app permissions

If you are using an Android device today, you have little control over apps once you install them.  This means you don’t know how the app is using any permissions you may have granted.  Some mobile security apps, like McAfee Mobile Security help by alerting you to permissions when you download an app. They can also inform you if the app is able to do something you don’t expect.

Tip 3:  Avoid third party app stores and direct download sites; get your apps directly from the Play Store, Apple Store or Microsoft

The reports of mobile malware are staggering and we asked Hinchliffe to help us better understand the landscape. McAfee Labs reports a staggering 6 million mobile malware samples in their zoo (see chart), most of which are designed for Android. Few mobile breaches, however, have been reported. “When you look at data breaches as a whole, like the Verizon Data Breach Investigation Report does, stats in the mobility vector are low,” says Hinchliffe. “This can be deceiving because mobile malware is evolving from spyware to more dangerous capabilities that give the attacker remote control over the device, or to encrypt your cherished photos and other data then hold them to ransom.”

Just as attackers learn how to gain control of devices, more and more users are switching to mobile payments. In fact, overall dependence on mobile devices is growing with reported usage of more than 30 hours a month.

“The primary method of installing malware on mobile remains consistently via apps delivered through third-party app stores or direct download sites,” says Hinchliffe.

Tip 4:  Don’t click hyperlinks sent in SMS messages – even links in messages sent from trusted contacts

The scariest scenario involves SMishing (SMS phishing). “Mobile attackers are sending SMS (text) messages, prompting users to click a hyperlink to a direct download site,” describes Hinchliffe. “Unsuspectingly, they download malicious apps and, if installed, lose control of their data or even their device.”

Tip 5:  Avoid connecting to your web accounts with mobile apps, or only connect to websites offering two-step verification

Bad apps are universal, as evident by recent reports showing thousands of apps in Apple’s App Store could be used to spy on your communications. Further, McAfee found 18 of the 25 most downloaded apps from all primary app stores remain vulnerable to man-in-the-middle (MITM) attacks four months after the vulnerabilities had been reported.

“This means that all communications between the mobile apps and their websites, including usernames and passwords, are potentially viewable by cybercriminals,” says Hinchliffe.Your Tasks

Subway, Sandwiches & Security

Remember that wallpaper they used to have at Subway sandwich shops? You know, with all the pictures of clunky, outdated modes of transportation? Subway’s wallpaper always provided an interesting window into the past and gave the place a sense of nostalgia.

So, imagine security researchers’ surprise when it was uncovered that Subway’s mobile app is anything but old-fashioned and in fact, employs some of the toughest and most technologically advanced security standards available.

Recently, a white hat hacker attempted to crack the Subway mobile app just so consumers would know whether or not their payment data was safe. In the end, this researcher did succeed, but he also uncovered some interesting quirks along the way.

What this researcher found was the kind of impregnable built-in security features normally used by mobile apps in the financial industry. For example, the app uses a custom app signature verification process, signaling that its guards are up against reverse engineering.

This means that the Subway mobile app has systems in place to prevent hackers from breaking through their site with fraudulent certificates. When a hacker attempts to get through, perhaps to access users’ payment information, they will instead be greeted by a popup stating that the verification has failed, calling out the hacker for tampering with the mobile app.

While this high level of security is certainly commendable, it also poses a question – why would a mobile app used for ordering sandwiches go to such great lengths in the name of cybersecurity?

One theory is that Subway appears to be responding to the recent spike in threats that have developed in the mobile space.

As was unveiled in the most recent McAfee Labs Threats Report, the number of new mobile malware samples jumped 49% between the first quarter of 2014 and the first quarter of 2015, a sobering statistic.

If Subway’s security efforts are any indication, it would seem that companies across all industries are feeling the pressure to implement tighter security measures in their mobile apps.

However, it’s never wise to rely on mobile apps alone for keeping your information safe and secure. So, while these mobile apps refine their privacy measures and work to introduce higher levels of protection, let’s take security into our own hands.

Having comprehensive security installed on your mobile device is key. McAfee® Mobile Security is free for Android and iOS users, and provides a variety of protections that will help keep unwanted eyes off of your devices.

Another quick tip? Be sure to pay close attention to the permissions that your mobile apps are requesting. A wallpaper app for instance, shouldn’t need access to your texts or location and may be up to something fishy if it’s trying to request access to them.

As always, to keep up with the latest security threats, make sure to follow @IntelSec_Home on Twitter and like us on Facebook.


Effect of Hacking on Stock Price, Or Not?

I read Brian Krebs story Tech Firm Ubiquiti Suffers $46M Cyberheist just now. He writes:

Ubiquiti, a San Jose based maker of networking technology for service providers and enterprises, disclosed the attack in a quarterly financial report filed this week [6 August; RMB] with the U.S. Securities and Exchange Commission (SEC). The company said it discovered the fraud on June 5, 2015, and that the incident involved employee impersonation and fraudulent requests from an outside entity targeting the company’s finance department.

“This fraud resulted in transfers of funds aggregating $46.7 million held by a Company subsidiary incorporated in Hong Kong to other overseas accounts held by third parties,” Ubiquiti wrote. “As soon as the Company became aware of this fraudulent activity it initiated contact with its Hong Kong subsidiary’s bank and promptly initiated legal proceedings in various foreign jurisdictions. As a result of these efforts, the Company has recovered $8.1 million of the amounts transferred.”

Brian credits Brian Honan at CSO Online, with noticing the disclosure yesterday.

This is a terrible crime that I would not wish upon anyone. My interest in this issue has nothing to do with Ubiquiti as a company, nor is it intended as a criticism of the company. The ultimate fault lies with the criminals who perpetrated this fraud. The purpose of this post is to capture some details for the benefit of analysis, history, and discussion.

The first question I had was: did this event have an effect on the Ubiquiti stock price? The FY fourth quarter results were released at 4:05 pm ET on Thursday 6 August 2015, after the market closed.

The “Fourth Quarter Financial Summary: listed this as the last bullet:

“GAAP net income and diluted EPS include a $39.1 million business e-mail compromise (“BEC”) fraud loss as disclosed in the Form 8-K filed on August 6, 2015″

I assume the Form 8-K was published simultaneously, with earnings.

Next I found the following in this five day stock chart.

5 day UBNT Chart (3-7 August 2015)

You can see the gap down from Thursday’s closing price, on the right side of the chart. Was that caused by the fraud charge?

I looked to see what the financial press had to say. I found this Motley Fool article titled Why Ubiquiti Networks, Inc. Briefly Fell 11% on Friday, posted at 12:39 PM (presumably ET). However, this article had nothing to say about the fraud.

Doing a little more digging, I saw Seeking Alpha caught the fraud immediately, posting Ubiquiti discloses $39.1M fraud loss; shares -2.9% post-earnings at 4:24 PM (presumably ET).  They noted that “accounting chief Rohit Chakravarthy has resigned.” I learned that the company was already lacking a chief financial officer, so Mr. Chakravarthy was filling the role temporarily. Perhaps that contributed to the company falling victim to the ruse. Could Ubiquiti have been targeted for that reason?

I did some more digging, but it looks like the popular press didn’t catch the issue until Brian Honan and Brian Krebs brought attention to the fraud angle of the earnings release, early today.

Next I listened to the archive of the earnings call. The call was a question-and-answer session, rather than a statement by management followed by Q and A. I listened to analysts ask about head count, South American sales, trademark names, shipping new products, and voice and video. Not until the 17 1/2 minute mark did an analyst ask about the fraud.

CEO Robert J. Pera said he was surprised no one had asked until that point in the call. He said he was embarrassed by the incident and it reflected “incredibly poor judgement and incompetence” by a few people in the accounting department.

Finally, returning to the stock chart, you see a gap down, but recovery later in the session. The market seems to view this fraud as a one-time event that will not seriously affect future performance. That is my interpretation, anyway. I wish Ubiquiti well, and I hope others can learn from their misfortune.

Update: I forgot to add this before hitting “post”:

Ubiquiti had FY fourth quarter revenues of $145.3 million. The fraud is a serious portion of that number. If Ubiquiti had earned ten times that in revenue, or more, would the fraud have required disclosure?

The disclosure noted:

“As a result of this investigation, the Company, its Audit Committee and advisors have concluded that the Company’s internal control over financial reporting is ineffective due to one or more material weaknesses.”

That sounds like code for a Sarbanes-Oxley issue, so I believe they would have reported anyway, regardless of revenue-to-fraud proportions.