Pointers for Mobile App Certificate Pinning

We often get questions about Certificate Pinning in mobile applications. Many clients find the issue difficult to explain to other teams.

You can find really great write ups, and an excellent set of source code examples for fixing this issue – as well as explaining it – at this OWASP.org site.

At a super high level though, you basically want your mobile application to validate the SSL certificate of the specific server(s) that you want it to talk to, and REJECT any certificates that do not match the intended server certificate – REGARDLESS of whether or not the underlying OS trusts the alternative certificate.

This will go a long way to hardening the SSL communication streams between the app and the server, and will not permit easy interception or man-in-the-middle attacks via a network provider or hostile proxy server.

Updates to the app source code are needed to mitigate the issue, and you may need to update apps in the app stores, depending on the way your app is delivered.

As always, if you work with MSI on mobile app security reviews or application-specific penetration testing, we would be happy to demonstrate the attacks and suggested mitigations for any identified issue. Just let us know if you would like assistance.

As always, thanks for reading and I hope your team finds this useful.

Getting Smart with Mobile App GeoLocation to Fight Fraud

If your mobile application includes purchases with credit cards, and a pickup of the merchandise, then you should pay attention to this.

Recently, in our testing lab and during an intelligence engagement, we identified a fraud mechanism where stolen credit cards were being used via the mobile app in question, to fraudulently purchase goods. In fact, the attackers were selling the purchase of the goods as a service on auction and market sites on the dark web.

The scam works like this. The bad guys have stolen credit cards (track data, likely from dumps), which they use to make a purchase for their client remotely. The bad guys use their stolen track data as a card not present transaction, which is standard for mobile apps. The bad guys have access to huge numbers of stolen cards, so they can burn them at a substantial rate without impacting their inventory to a large extent. The bad guy’s customer spends $25 in bitcoins to get up to $100 in merchandise. The bad guy takes the order from the dark net, uses the mobile app to place the order, and then delivers the receipt and/or pickup information to the bad guys customer. The customer then walks into the retailer and shows the receipt for their mobile order, picking up the merchandise and leaving.

The bad guy gets paid via the bitcoins. For them, this is an extremely low risk way to convert stolen credit card info to cash. It is significantly less risky for them than doing physical card replication, ATM use or other conversion methods that have a requirement for physical interaction.

The bad guy’s customer gets paid by picking up the merchandise. They get up to $100 value for a cost of $25. They take on some risk, but if performed properly, the scam is low risk to them, or so they believe. In the odd event, they simply leave the store after making their demands for satisfaction. There is little risk of arrest or prosecution, it would seem, especially at the low rate of $100 – or at least that was how the bad guy was pitching it to their prospective customers…

The credit card issuer or the merchant gets stuck. They are out the merchandise and/or the money, depending on their location in the world, and the merchant agreement/charge back/PCI compliance issues they face.

Understanding the fraud and motivations of the bad guys is critical for securing the systems in play. Organizations could up their validation techniques and vigilance for mobile orders. They could add additional fraudulent transaction heuristics to their capability. They could also implement geo-location on the mobile apps as a control – i.e.. If the order is being physically placed on a device in Ukraine, and pick up is in New York, there is a higher level of risk associated with that transaction. Identifying ways  to leverage the sensors and data points from a mobile device, and rolling it into fraud detection heuristics and machine learning analytics is the next wave of security for some of these applications. We are pleased to be helping clients get there…

To hear more about modern fraud techniques, application security testing or targeted threat intelligence like what we discussed above, drop us a line (info at microsolved dot com) or via Twitter (@lbhuston). We look forward to discussing it with your team.

Involved in M&A Activity? MSI has a full M&A Practice

 

MSI’s specialized offerings around Mergers & Acquisitions are designed to augment other business practices that are common in this phase of business. In addition to general security consulting and intelligence about a company from a “hacker’s eye view”, we also offer deeply integrated, methodology-driven processes around:

  1. Pre-negotiation intelligence
    1. This offering is designed to help the purchasing organization do recon on their prospect for purchase. Leveraging techniques like passive assessment, restricted individual tracing, supply chain analysis, key stakeholder profiling and history of compromise research, the potential purchasing company can get deep insights into the security posture and intellectual property integrity of the company they are considering for acquisition. All of this can be done passively and prior to a purchasing approach or offer. Insights from this service can be a useful tool in assessing approach and potential valuation. 
  2. Pre-integration assessments 
    1. Once the ink on the paperwork is dry, the organizations have to learn to live and work together. One of the most critical links, is the joining of the two IT infrastructures. In this service, our experts can perform assessments to analyze the new company’s security posture against the baseline standards of the purchasing organization. A gap analysis and road map for compliance can be provided, and if desired, MSI can serve as oversight for ensuring that the mitigations are completed as a condition for network interconnection and integration. Our team has performed these services across a variety of M&A completions, including multi-national and global Fortune 500 organizations.
  3. Post-purchase threat intelligence 
    1. MSI can also create mechanisms post-purchase to identify and respond to potential threats from inside the newly acquired organization. Our counter-intelligence and operational security techniques can help organizations identify potential internal bad actors or disgruntled new employees that could be seeking to damage the acquirer. We have created these solutions across a myriad of verticals and are quite capable of working in international and other highly complex environments. 

To learn more about these specific offerings, click on the links above. To discuss these offerings in more detail, please contact your account executive for a free consultation.

Plus, we also just added some new capabilities for asset discovery, network mapping and traffic baselining. Check this out for some amazing new ways we can help you!

Never Store Anything on the Cloud that You Wouldn’t Want Your Mamma to See

It’s great now days, isn’t it?

You carry around devices with you that can do just about anything! You can get on the Internet and check your email, do your banking, find out what is new on Facebook, send a Tweet or a million other things. You can also take a picture, record a conversation, make a movie or store your work papers – and the storage space is virtually unlimited! And all this is just great as long as you understand what kind of risks this freedom poses to your privacy.

Remember that much of this stuff is getting stored on the cloud, and the only thing that separates your stuff from the general public is a user name, password and sometimes a security question. Just recently, a number of celebrities have complained that their photos (some of them explicit) have been stolen by hackers. These photos were stored in iCloud digital vaults, and were really very well defended by Apple security measures. But Apple wasn’t at fault here – it turns out that the celebrities themselves revealed the means to access their private stuff.

It’s called Phishing, and there are a million types of bait being used out there to fool or entice you. By clicking on a link in an innocent-looking email or answering a few simple questions, you can give away the keys to the kingdom. And even if you realize your mistake a couple of hours later, it is probably already too late to do anything about it. That naughty movie you made with your spouse during your romantic visit to Niagara Falls is already available from Peking to Panama!

Apple announced that they will soon start sending people alerts when attempts are made to change passwords, restore iCloud data to new devices or when someone logs in for the first time from new Apple devices. These are valuable controls, but really are only detective in nature and won’t actually prevent many data losses. That is why we recommend giving yourselves some real protection.

First, you should ensure that you educate yourself and your family about the dangers hackers and social engineers pose, and the techniques they use to get at your stuff. Second, it is really a lot better to store important or sensitive data on local devices if possible. But, if you must store your private data in the cloud, be sure it is well encrypted. Best of all, use some sort of good multi-part authentication technique to protect your stuff from being accessed easily by hackers. By that I mean something like a digital certificate or an RSA hard token – something you have or something you are, not just something you know.

If you do these things, then it’s a good bet your “special moments” won’t end up in your Momma’s inbox!

Thanks to John Davis for this post.

Ask The Security Experts: Mobile Policy

This time around, the experts offer insights on this question:

Q: “Dear Experts, what are the key things I need to keep in mind when I write my company’s mobile security policy?” — MK

John Davis starts us off with:

I would say the most important thing is to actually write your own policy; don’t just copy a generic mobile security policy from the Internet and adopt it as your own. For a mobile security policy to be effective, it needs to be tailored to meet your organizations particular information security requirements and also needs to reflect the reality of mobile device use at your organization. It won’t do you much good to forbid using mobile devices for business purposes if you have no mechanisms in place to prevent or detect such uses. Effective information security policy, like effective statute law, is both practical and enforceable.

Adam Hostetler added:

Keep in mind what kind of current security policies you have, and try to apply that to the mobile sphere. Users need to understand that they are connecting an additional computer to the network, and not just a “phone”. Keep in mind also what kind of deployment you are using. Is it bring your own device, or is it company provided? There will be different policies and procedures for each method and possible user backlash depending on how you are doing this.

As always, thanks to the experts for weighing in, and to the readers for the questions. Keep them coming!

Resources for Mobile Application Security

Mobile application security continues to be a hot topic within the information security community. With more and more employees expecting to use their own devices at their workplaces, IT departments are scrambling to develop the right approach for securing their data.

If you’re working on developing security policies or seeking ways to secure your mobile applications, you may find some of these resources helpful. Stay safe out there!

How to Save Your Photos From a BYOD Security Policy

Many companies have adopted a BYOD policy regarding mobile devices. Realizing that it’s unrealistic to require employees to leave their iPhones or tablets at home, they’ve accepted mobile technology; albeit, with a few rules.

One of the more common rules is to enable the remote wipe and lock feature. This means that if your device was ever stolen or compromised, the IT department can remotely lock the device and then wipe any data from it. And yes, that would include all of your photos as well as other items.

One CEO recently experienced personal data loss as a result of his own company’s policy that he himself helped establish. (Ouch!) While on vacation, his five-year old daughter tried to use his smartphone. After several failed attempts of entering the passcode, the corporate-installed remote wipe was triggered and the CEO lost all of the photos he had taken during the first half of their vacation. (Double ouch!)

If you have an iPhone with the latest iOS 5, you can sign up for the free iCloud, which will sync your devices and store everything on Apple’s servers. But first, you have to enable it. After installing the iCloud feature, tap Settings/iCloud and then choose “On.” Click on the “Back Up Now” and you’re good to go. This way, if your device is wiped clean because of a security breach, you’ll still have your photos. 

Again, you’ll have to remember to do this frequently if you are using your smartphone to take vacation photos. It may be a good idea to back up your data during dinner or before you go to bed.

If you have an Android phone, make sure you have a Gmail address in order to take advantage of storing your data in the cloud. Titanium Backup and MyBackup Pro are also two apps that can back up your entire phone and transfer the data to your PC’s hard drive.

Whatever device you use, make sure you have a back up plan. Know well your company’s BYOD policy. It will give you peace of mind the next time you’re taking a bunch of photos at an event that will never happen again.

Stay safe and enjoy the ride!

Follow Up to Out of Band Authentication Post

(This is a commentary follow up to my earlier post, located here.)

A couple of folks have commented on Twitter that they have a fear of using SMS for any sort of security operations. There have been discussions about the insecurity of SMS and the lack of attention to protecting the cellular network by carriers around the world. I generally disagree with blanket statements, and I would push for organizations considering SMS as a means of authentication to undertake a real risk assessment of the process before they jump in.
 
However, if the controls in place in the cell networks meet their appetite for risk, then I think it is a perfectly acceptable business case. It certainly beats in-band simple authentication mechanisms like “pictures of trust” and traditional login/password as a security control.
 
At least in SMS authentication, the attacker would usually need to have control over or access to more than one device belonging to the user. I think this helps make the risk model more acceptable for my views.
 
Other folks discussed how Out of Band Authentication (OOBA) has been done now successfully in many places. I agree with this. We know how to do it. There are a LOT of vendors out there who can successfully integrate, deploy and manage a solution for you. Sadly, though, there are still more than a few who are struggling to get it right or done at all. As with most things in life, it helps to do a little research. Organizations should perform due diligence on their vendors and factor vendor risks into the equation of purchases and project planning. 
 
Lastly, a few folks commented on the fact that they, too, are running into speed bumps with deployments and logistics. Several folks echoed the sentiments of the original challenges and few offered suggestions beyond simply “doing more homework” and looking for “quickly scalable solutions”. The good news with this is that you are not alone out there. Other folks are facing AND BEATING challenges. Feel free to reach out to your peers and discuss what is and what isn’t working for them.
 
As per the original post, the more communication and discussion we can have amongst the community about these topics, the better off we all will be. So, discuss, seriously…
 
##Special thanks to the vendors that replied with case studies, references or stories about how they have done integration and deployment. There are a lot of good vendors out there with knowledge in this area. Careful review of their capabilities will help you sort them out from the less capable. Communication is key.
 
Thanks for reading! 

Financial Organizations Struggle with Out of Band Authentication

Many of our client financial organizations have been working on implementing out of band authentication (OOBA) mechanisms for specific kinds of money transfers such as ACH and wires.

 A few have even looked into performing OOBA for all home and mobile banking access. While this authentication method does add some security to the process, effectively raising the bar for credential theft by the bad guys, it does not come without its challenges.

For starters, the implementation and integration of some of the software designed for this purpose has been a little more difficult than expected by many of the teams working on the projects. We are hearing that in some cases, the vendors are having difficulty integrating into some of the site platforms, particularly those not using .NET. Other platforms have been successful, but over time (and many over budget), the lesson learned is this: communicate clearly about the platforms in use when discussing implementations with potential vendors.
 
Other problems we have been hearing about include: availability issues with the number of outbound phone connections during peak use periods, issues with cellular carriers “losing” SMS messages (particularly a few non-top tier carriers), and integrating solutions into VoIP networks and old-style traditional PBX systems.
 
In many cases, these telephonic and cellular issues have caused the systems to be withdrawn during pilot, even turned off for peak periods during use and other “fit and start” approaches as the rough patches were worked out. The lesson in this area seems to be to design for peak use as a consideration, or at least understand and communicate acceptable delays, outages or round-robin processes, and make sure that your systems properly communicate these parameters to the user.
 
In the long run, proper communication to the users will lower the impact of the onslaught some of these systems call to the customer support and help desk folks.
 
It is getting better though. Vendors are learning to more easily and effectively develop and implement these solutions. The impact on account theft has been strong so far and customers seem to have a rapid adjustment curve. In fact, a few of our clients have shared that they have received kudos from their members/customers for implementing these new tools when they were announced, documented, and explained properly to the user base.
 
If your organization is considering this technology and has struggled with it, or has emerged victorious in the mastery of it; please drop me a line on Twitter (@lbhuston) and let me know your thoughts. The more we share about these tools, the better we can all get at making the road less bumpy for the public.
 
As always, thanks for reading and stay safe out there!

Mobile Apps Shouldn’t Roll Their Own Security

An interesting problem is occurring in the mobile development space. Many of the applications being designed are being done so by scrappy, product oriented developers. This is not a bad thing for innovation (in fact just the opposite), but it can be a bad thing for safety, privacy and security.

Right now, we are hearing from several cross platform mobile developers that the API sets across iOS, Android and others are so complex, that they are often skipping some of the APIs and rolling their own code methods for doing some of this work. For example, take crypto from a set of data on the device. In many cases, rather than using standard peer-reviewed routines and leveraging the strength of the OS and its controls, they are saying the job is too complex for them to manage across platforms so they’ll embed their own code routines for doing what they feel is basic in-app crypto. 

Problems (like those with the password vault applications), are likely to emerge from this approach toward mobile apps. There is a reason crypto controls require peer review. They are difficult and often complex mechanisms where mistakes in the logic or data flows can have huge impacts on the security of the data. We learned these lessons long ago. Home-rolled crypto and other common security routines were a big problem in the desktop days and still remain so for many web applications, as well. Sadly, it looks like we might be learning those lessons again at the mobile application development layer as well.
 
Basically, the bottom line is this; if you are coding a mobile application, or buying one to access critical data for your organization, make sure the developers use the API code for privacy, trust and security functions. Stay away from mobile apps where “roll your own/proprietary security code” is in use. The likelihood of getting it right is a LOT less than using the APIs, methods and code that the mobile OS vendors have made accessible. It’s likely that the OS vendors are using peer-reviewed, strongly tested code. Sadly, we can’t say that for all of the mobile app developer code we have seen.
 
As always, thanks for reading and stay safe out there!