Thursday, July 25, 2013

‘Beebone’ computer virus lurking in Indian cyberspace

A new and deadly variant of computer virus called ‘Beebone’ has been detected in Indian cyberspace and Internet security sleuths have warned users to safeguard their systems against its attack which leads to unauthorised entry of malware.
’Beebone’ belongs to the notorious family of Trojan malwares which get a “privileged access” into a users computer by faking its identity and deploying smart and corrupt techniques to attack vulnerable computers.
The latest virus detected on the country’s Internet network is so notorious and lethal that it acquires as many as 20 aliases or masks to infect and attack a vulnerable computer system which is low on security features.
“It has been observed that new variants of Trojan win32/Beebone are spreading widely. This is a trojan downloader family which silently downloads and installs other malware and programs without user consent,” an advisory issued by the national Internet and computer security sleuths organisation, the Computer Emergency Response Team-India (CERT-In), said.
The cyber security sleuths have suggested a host of countermeasures and defences to beat ‘Beebone’ attacks.
“Exercise caution while using external/removable storage devices, disable autorun functionality in Windows, keep upto date patches and fixes on the operating system and application software, do not visit untrusted websites, keep upto date anti-virus and anti-spyware signatures at desktop and gateway level, use strong passwords and also enable password policies and avoid downloading pirated software,” are some of the security features recommended by the agency to Internet and computer users in the country.
For computer technology geeks, the agency has put out the names of aliases acquired by the virus.
Some of them are – Trojan.Win32.Jorik.Fareit.qru (Kaspersky), W32/Autorun.worm.aaeh!gen (McAfee), W32/VobFus-BX (Sophos), Trojan horse (Symantec), Trojan-FBZZ! 41E0B7088DD9 (McAfee), Trojan.Win32.SelfDel.aqhh (Kaspersky), Trojan.Win32.Jorik.Fareit.qsl (Kaspersky), Beebone-FMQ! 039FA2520D97 (McAfee), W32.Changeup! gen40 (Symantec) and Worm.Win32.Vobfus.dxpf (Kaspersky).

Wednesday, July 24, 2013

Secure your mobile applications

Find vulnerabilities with IBM Security AppScan Standard
With the explosive growth in the mobile ecosystem, mobile application security is a huge concern. New mobile application designs require new ways of testing to ensure data safety. In this article, explore different aspects of mobile application security. With hands-on examples, learn to use IBM® Security AppScan® Standard with mobile user agents and with emulators and actual devices for Android and iOS.
In the rapidly growing mobile ecosystem, mobile application security is a hot topic with IT security staff, researchers, and leaders. Mobile application development incorporates new design principles that require developers to pay attention to new methods for ensuring data safety. Testing your mobile applications and associated infrastructure can be an effective way to increase the security of your mobile solutions.

This article discusses mobile application security and provides hands-on techniques for configuring the dynamic testing of mobile application servers using IBM Security AppScan Standard Edition. Learn to set up AppScan to scan mobile applications with three different models:
  • Using an emulator for both iOS and Android
  • Configuring an actual mobile device for both Android and iOS
Figure 1 shows the three different configurations.

Figure 1. Methods to scan and test mobile applications
Image showing the three different model types 
As Omri Weisman described in his recent webcast (see Resources), mobile applications can be divided into several categories. Your mobile application's category determines which testing techniques and corresponding tools can be used most effectively.
Mobile native applications are targeted to run on the device and are written in a native language, such as Java for Android applications or Objective C for Apple iOS applications. Applications in this category are best tested with static analysis tools. IBM Security AppScan Source Edition version 8.6 and higher supports the static analysis of Android applications. However, many native applications also use standard web and web service communications interfaces that can often be tested using IBM Security AppScan Standard Edition.
Mobile web applications are just as the name implies. Instead of developing a native application for each of the mobile platforms, many organizations will add support for mobile devices to their existing websites. Or, they'll develop specific websites to support mobile applications. This support often includes streamlined navigation, reduced bandwidth requirements, optimization for smaller screen sizes, different technology (for example, HTML5 versus Flash), and so on. Thus, the "application" deployed to the mobile device is often little more than a shortcut or bookmark. Applications in this category are well suited for both static testing using AppScan Source Edition and dynamic testing using AppScan Standard Edition.
Hybrid mobile applications often consist of a web-based (HTML, CSS, JavaScript) user interface (WebView/UIWebView) surrounded by a layer of native application. Applications in this category are also well suited for both static testing using AppScan Source Edition (for Android) for the native layers and dynamic testing using AppScan Standard Edition for the web-based layers of the application.
For each type of mobile application, there's a common model that involves splitting processing between the mobile portion that's deployed to the mobile device and a central processing, or data storage, portion that's deployed to a server. This model often uses a web service interface that can be tested directly using AppScan. AppScan supports the testing of a wide variety of web services, including those that are SOAP-based and REST-based.
The methods described in this article should test the interfaces of the web service used by your application. However, for further security, you must still ensure that the web service is comprehensively tested, including all implemented functions not currently used by the mobile application. AppScan only tests the interfaces it is made aware of during the exploration phase.
Communication with the mobile web or application server is often through standard protocols and data formats that can be intercepted, such as HTTP, HTTPS, SOAP, REST, JSON, and XML. The mobile application server can be tested using IBM Security AppScan Standard Edition. The following sections describe methods to configure AppScan to capture these interactions—an essential step in testing mobile web application servers. You'll learn about the three methods (in Figure 1) to test mobile application servers with AppScan: configuring the user agent, using the emulators, and using the actual mobile devices.
The easiest way to test mobile application servers is to configure AppScan to send User-Agent strings that mimic mobile devices. AppScan has added native support for a large variety of devices; it has the ability to configure any custom User-Agent strings that may be necessary.
You can set the User-Agent string by selecting Explore Options from the Scan Configuration window, as shown in Figure 2. Then, test the server portion of the mobile application as you normally would with URLs, manual recordings, web service interaction, and so on.

Figure 2. Set up user agent
Sceen shot of the scan configuration window 
This method is a good match for mobile web applications, and it should be familiar if you have experience using AppScan to test web applications. Making simple configuration changes should be sufficient for testing most applications.
Another technique for testing mobile applications is to run the application in the software emulator and proxy its traffic through AppScan. This section provides details for Android and iOS.
You can configure an Android emulator by using the emulator that is included with the Android SDK. When the application is running in the emulator, the network traffic can be directed through the AppScan Proxy Port available on the localhost address (127.0.0.1) at the port specified in the AppScan > Tools > Options window, as shown in Figure 3. By default, this port is picked dynamically. If you're using this feature actively, consider setting it to a static value by unchecking the "Let AppScan choose the port automatically" checkbox and setting your preferred port in the "AppScan proxy port" field.

Figure 3. Set up proxy
Screen shot of the options window 
Configure the Android emulator to use this proxy port on the localhost address in the emulator command line using the following command.
emulator -avd myAVD -http-proxy 127.0.0.1:{port from appscan config}

If you're launching the emulator from Eclipse, you can configure this setting from Window > Preferences > Android >Launch >Default Emulator Options. Note that the proxy configurations in the device and emulators may not be used by some applications. In such cases, other approaches, including development support, may be required.
In some versions of the Android OS, you may be able to configure a proxy from within the emulator instead of using the command line. If you do so, be aware that in the Android OS you will need to use a different proxy address: 10.0.2.2. This is a special address that corresponds to the loopback interface on your local PC (127.0.0.1). It is needed because 127.0.0.1 is used by the emulated Android OS as its own internal loopback port.
In Android 4.1, to adjust the proxy setting:
  1. Go to the Settings menu.
  2. Select More under Wireless and networks.
  3. Select Mobile network settings.
  4. Select Access Point Names.
  5. Select the network listed.
  6. Modify the Proxy and Port fields, as shown in Figure 4.
  7. Ensure that the username is blank and a password is not set.

Figure 4. Android OS level configuration
Screen shot of the Network screen with web proxy            http checked and the web            proxy server address entered 
The iOS simulator does not have dedicated proxy settings, but it's easy to set a proxy for all network traffic using a Mac computer. In Preferences > System preferences, select Networking and choose the interface that you are using (wired or wi-fi). Under the Advanced setting, you'll see a proxy tab, as shown in Figure 5. Set the IP and port to that of the machine where you are running AppScan. The AppScan proxy only binds to local traffic, so you'll need to make configuration changes to forward incoming traffic to a local adapter (see Using an iOS mobile device).

Figure 5. Set up iOS proxy
iOS proxy screen 
If you want to explore from your actual mobile device, some additional configuration is required. As mentioned, the AppScan proxy binds to the localhost loopback address only (127.0.0.1). You need to be able to make this proxy port available on an available interface.
There are many utilities to help you configure a mobile device. The example in this article uses rinetd (see Resources), an Open Source (GPL 2+) utility that is easy to use, widely available, and free. After you've downloaded the rinetd utility to the PC where AppScan is installed, rinetd installation is as simple as extracting the zip file and placing the executable in the location of your choice.
After installation, you'll need to create a very simple configuration file. The format and features for the file are fully documented on the rinetd site. The example in this article requires a single line:
(IP to listen on) (port to listen on) (IP to forward to) (port to forward to)
192.168.1.114 28080 127.0.0.1 18080

This configuration line instructs rinetd to listen to the IP address 192.168.1.114 on port 28080 and forward all traffic to 127.0.0.1 on port 18080 (presumably where AppScan is configured to listen). You can place this line into a text file called rinetd.conf, or anything else of your choice, then run rinetd from the command line with the following statement.
rinetd -c c:\PATH\TO\CONFIG\rinetd.conf

After rinetd is running, you'll be able to proxy a device's traffic through the available IP address and port to the AppScan proxy port on the local loopback address.
After configuring rinetd, you'll need to configure your Android device to proxy using the rinetd IP and port (192.168.1.114 and 28080 in the example). Select Settings > Wi-Fi and modify the current network, as shown in Figure 6.

Figure 6. Set up Android proxy
Screen shot of the proxy settings for Android 
Similarly, on an iOS device you'll need to set the HTTP proxy from the Settings > Wi-Fi configuration screen. Set the Server and Port to those configured in rinetd (192.168.1.114 and 28080 in the example).

Figure 7. Set up iOS
Screen shot of the iOS server and port 
After you've set up your proxy configuration using any of the methods above, the next step is to configure a scan and begin a manual exploration.
In the emulator or device, run the application that you want to test. As you explore the application features, the traffic generated is routed through the AppScan proxy for recording. When you're done manually exploring with the emulator or device, close the browser and the traffic is loaded into the configuration. When all recording is complete, you're ready to begin testing. You can reconfigure the mobile devices and should shut down rinetd (if used).
Testing for security is very similar to the testing of typical web applications and web services. The test policy that you select will most likely be geared to testing the mobile web application, possibly with application only, vital few, or developer's essentials. It's a good idea to also test the associated infrastructure periodically. Organizations sometimes treat mobile application servers differently in terms of policy, procedures, and standards, even though they are often, in essence, web application servers and web servers.
You might need to do some additional configuration to support the communications methods for your application. Web service methods, such as SOAP or REST, may often be used. AppScan includes tests for testing SOAP methods. It can also be configured to test RESTful services. Check out Ory Segal's article on this topic (see Resources) on the Application Security Insider blog.
Mobile applications can operate in varied and high-risk network environments, so transport layer encryption (SSL/HTTPS) is often critical. Properly implemented transport layer encryption can present challenges when testing with the emulator or simulators or from the actual devices. The AppScan proxy must function as a "man in the middle" in order to capture the encrypted traffic.
Challenges with transport layer encryption can usually be overcome by adjusting configuration settings in the application or device or simulator, thereby establishing trust with the AppScan certificate. However, in certain cases development support may be required, such as for non-configurable pinned certificates. Detailed configuration settings for mobile devices or the emulators are beyond the scope of this article.
If your organization isn't currently supporting mobile applications, it likely soon will be. In this article, you learned about mobile application security with some hands-on techniques to dynamically test the security of mobile application servers using IBM Security AppScan Standard Edition.

Learn

Tuesday, July 23, 2013

5 Risks Introduced by Mobile Apps

About four years ago, Apple released the first mobile device App Store, and three major players followed: Google Play, Windows Store and Blackberry App World. Additionally, a plethora of secondary application markets exist, all of which combined serve over 1.5 million apps today.
 If there is something that can be done from your device, 'there's an app for that' - and a risk. 
As a result of these apps, we users have become more dependent on our smart phones and tablets. These devices accompany us virtually everywhere, including at work. In the workplace, executives soon recognized the potential for increased productivity from mobility and started allowing personal devices to connect to corporate networks, including e-mail. This paradigm shift in the way people live and work spawned a flurry of bring-your-own-device and mobile device management design and implementation activities among many organizations.
But in the rush to allow personal devices to be used for work, we in application security neglected to examine thoroughly the new risks external applications may introduce to our organizations.

Risky Business

All of the apps from app stores have one thing in common: If there is something that can be done from your device, "there's an app for that" - and a risk. My smart phone's alarm is the first thing I hear in the morning. Once I shut off the Super Mario Brothers' musical theme, I type in my eight-digit passcode, open one of four weather apps to prepare for the day, check my e-mail to see if there is anything pressing, peruse local news and glance at friends' updates on Facebook. From the time I first hear the Super Mario Brothers' call to meet the day, to checking weather, news, friends' activities and a work update, a mere 45 minutes has elapsed.
Our lives have become more efficient, and portions of it are consumed by mobile devices and what we can do with them. While we enjoy a myriad of efficiencies, we need to think about what having real-time access to everything we think we need means to our businesses. What types of risks do they bring and what do we need to worry about?

Top 5 Risks

Mobile applications have similar threats, vulnerabilities and risks to those posed by typical web and client/server applications. That said, because users have the power and ability to download whatever they wish and manage their devices to their liking, we need to think about these top five risks and how to mitigate them:
  1. Inherent, Blind Trust - App stores come pre-installed on our mobile devices and provide access to a ton of mobile applications. We blindly trust that the app stores have performed due diligence on the apps in their stores. Yet, in reality, app store vendors lack the cycles to ensure that the apps they make available won't open up our employees/users to risks that can harm the business.
  2. Functional Risks - Opening, editing, sending, receiving and e-mailing documents; syncing backups; checking in to my current location; etc. - these are a tiny subset of tasks that I can complete with my devices. But what happens if I open a PDF from my business e-mail into a PDF viewer that I downloaded? Suppose I then sync that document to the PDF viewer? At this point, my potentially sensitive document is being managed by someone else's application (probably insecure application and sync storage), and it is completely outside of my control. How about if I check in to my current location via Facebook or Foursquare? Due to the sensitive nature of what I do, some of my clients don't want others to know I am working for them, But if I "check in," the whole world (literally) becomes aware of where I am.
  3. Malware - Malware has forever been a problem in the IT world, and it is no different in the mobile sphere. Malware can wreak havoc by stealing sensitive data, monitoring traffic, connecting to internal networks and infecting internal machines. And that's just for starters. Malware will continue to evolve in apps from app stores, and attackers will continue to refine their approaches to malfeasance.
  4. Root Applications - Rooting and jailbreaking are commonplace. Users or attackers run exploits against the mobile operating system to provide them with unfettered access to the file system and allow them to be the "root" user of the operating system. Some users appreciate the freedoms that having root access gives them. Root access also provides a gateway to other app stores, such as Cydia, or the ability to download applications from untrusted sources. The applications running as root deliver functional and malware risks to the business. In some cases, the functional/malware line starts to get fuzzy with the root applications because, typically, the applications provide more functionality than the typical non-root applications provide.
  5. Inappropriate Applications - Clearly, not all applications are appropriate in the workplace, and I'll leave it to your imagination to classify which ones would be classified as Not Safe For Work.
The number of mobile applications has gone from zero to 1.5 million in a little more than four years, and it will continue to grow in quantum leaps. As the mobile app world continues to evolve, so will the risks. In next month's posting, I will discuss how to address each of these risks and provide specifics on how to thwart them.

Tips to Improve Mobile App Security

There are over 1.5 million applications available in public mobileapp stores. This number doesn't take into account the hundreds of applications within organizations that are available to internal personnel.
With organizations racing to be the first-to-market with the latest, coolest app, they are forgetting something critically important: applying security principles in the development and deployment. We must ensure that our mobile application projects put security at the forefront and not forget about it entirely.
 We must ensure that our mobile application projects put security at the forefront. 
With the utmost certainty, I can state, unequivocally, that every mobile device has an insecure application. New apps are being downloaded at stunning speed - faster and more than at any time in history. During Christmas week, 2012, 1.76 billion apps were downloaded from the Apple App Store and the Google Play Store and 50 million new iOS and Android mobile devices were activated.

How to Know What You Don't Know

Many organizations have the foresight to provide continuoustraining to their development staff so that they may reliably produce better, secure code. Educational options such as in-person, hands-on training via eLearning solutions are beneficial, and we are starting to see certain types of vulnerabilities crop up less often.
On average, it costs $1,000 to find a vulnerability and $4,000 to fix it. It's much more cost-effective to teach developers how to build security in at the outset. Certain classes of vulnerabilities, such as SQL Injection, were first discovered over a decade ago, yet continue to be pervasive. With better education and training, developers should be able to eradicate certain vulnerabilities from their organizations and not have the same issues crop up repeatedly.
While mobile development isn't any different from other application development efforts, it isn't treated the same. On average, we discover 11.6 vulnerabilities in every mobile application our practice verifies - code that's just like yours. Mobile applications present both new and existing threats. Understanding the key differences in operating systems and Application Programming Interfaces (APIs) is critical in creating secure mobile applications. There are many great mobile application security courses available for your organization's consideration. With over 1,000 vulnerabilities in existence today, developers cannot possibly be expected to create defensible applications without proper training.

Force Change in Application Security

Most organizations with application security programs have plenty of best practices, programming standards and the like, but all of these are specific to web applications or client/server applications. These practices must be updated and applied to mobile technologies. Is your organization using iOS, Android, Blackberry, Windows Phone 8, etc.? There are many ways to build and enforce your mobile application security program. Here are four things you can do:
  1. Develop Mobile Security Standards - And Apply Them! All organizations have some form of standards and guidelines for developers to follow when creating applications. However, their details are oftentimes not focused on security, and in most cases there is no mention of mobile applications. There are differences between Android and iOS when ensuring that auto-complete is turned off or password fields are appropriately protected - just as we would worry about in a browser. We must ensure that we have solid security standards and guidelines for all of the technologies that are in use. Do your standards and guidelines make mention of security or mobile security? Check out the OWASP Mobile App Sec Project for good, free resources to help you.
  2. Perform Design/Architecture Reviews with Threat Modeling - In general, applications are becoming increasingly more complex, using cutting-edge technologies and more backend resources. With the addition of the mobile channel, another level of complexity is added to our infrastructure that's highly intricate to begin with. In some cases, applications add new, use or enhance current infrastructures to support the new mobile channel. Adding a mobile channel requires a thorough design and architecture review with an emphasis on threat modeling. We must understand the new threat-scape with mobile applications and the potential risks to the business. Thorough design and architecture reviews that include the threat modeling technique help uncover the potential risks before an application goes live, so that remediation activities can be performed accordingly.
  3. Conduct a Manual Verification - After we've performed design/architecture reviews with threat modeling, it's time to conduct some level of manual verification. The scope and level of rigor will be determined by the amount of risk posed by the application. The application's size and complexity will determine the multiple levels of verification through iterative code reviews and penetration testing. Organizations must engage mobile verification experts to work alongside internal teams. Companies should have an eye towards building a strong testing group from within.
  4. Complete Dynamic and Static Verification - Dynamic and static verification techniques are still in their infancy and, as such, very little is available for the dynamic verification of mobile apps. However, that does not mean that these two security activities don't fit into the secure mobile development process. Once these technologies become more main-stream and efficient, we should make sure to evaluate our mobile code during development using static approaches to make sure bad APIs are not abused and that other security controls are coded appropriately. Dynamic and static analysis for mobile will continue to improve and fit nicely into our security activities.
Some applications will require higher levels of rigor and, as such, your organization should perform all of the aforementioned activities. In other cases, the risk level may warrant only manual or dynamic verification. Either way, mobile applications will only continue in their popularity. More push will come down from the business units to create more and more apps to improve employee efficiency and client needs. That being said, it is critical that every organization developing mobile apps have a well-defined and stable mobile application security process.

Top Threats to Mobile Devices

Malicious Apps, Targeted Attacks Are Major Concerns

Mobile threat research from the Anti-Phishing Working Group pinpoints key vulnerabilities, such as sophisticated malware baked into rogue mobile applications, says anti-phishing expert Dave Jevans.
Over the past six months, the APWG, a global consortium of industry leaders from various sectors, has analyzed emerging mobile security threats.
"There are a number of new attacks that are specifically targeted at mobile devices," Jevans, founder and chairman of the APWG, says in an interview with Information Security Media Group [transcript below].
"The criminal underground ... has taken their focus and started to move it toward the mobile platform with maliciousapps," he says.
Some malicious apps are designed to intercept SMS/text messages that compromise out-of-band online-bankingauthentication, Jevans says. Some are written to steal contact details. But other mobile attacks focus on networks. "Those include poisoning or takeover of the DNS or the Wi-Fi hotspot," he says.
"The big message here ... is that malicious and fraudulent activity on the mobile platform is growing much more quickly than it did on the PC platform," Jevans says.
Organizations have to be concerned about these risks and address them proactively, he says. "Anybody who is allowing their employees to bring these mobile devices into the workplace is at risk."
During this interview, Jevans discusses:
  • Key mobile user risks and technical considerations the APWG has noted in its latest mobile threat reports;
  • The authentication challenges U.S. banks are facing as more users adopt mobile banking;
  • How the multitude of mobile operating systems is complicating mobile-risk mitigation.
Jevans serves as chairman of the Anti-Phishing Working Group, a consortium of more than 1,500 financial services companies, Internet service providers, law enforcement agencies and technology vendors globally. He also is the founder of mobile security and cloud service provider Marble Security, formerly IronKey, and has been involved in Internet security for more than 15 years. Earlier, Jevans held senior management positions at Tumbleweed Communications, Valicert, Teros and Differential. He also served on the CEO's technology council at Apple Computer, helping formulate the company's Internet strategy. And he worked in the operating systems group and the advanced technology group at Apple, leading an engineering team that developed 3-D computer graphics systems for the Mac.

Mobile Threats

TRACY KITTEN: We've been talking about mobile threats for quite some time, but is there evidence now that some of these threats are actually materializing in the wild?
DAVE JEVANS: There is evidence, and we've published a research report and an addendum to it with technical information. It has been compiled over about six months with help from a number of the members of the APWG Mobile Working Group, a number of the security vendors out there, university folks and independent security researchers. What we're finding is that the criminal underground for the last five to 10 years has been targeting primarily PCs with malware, fraud schemes, phishing, spear-phishing and APTs, and have taken their focus and have started to move it toward the mobile platform with malicious apps, malware, Wi-Fi takeovers, big banking apps, etc.

Cyberthreats Aimed at Mobile

KITTEN: You've touched on malware and phishing, but are there new cyberthreats that are aimed at mobile that the APWG has now identified?
JEVANS: We've identified a number of new attacks that are specifically targeted at users of mobile devices. On the PC side of things, most of the attacks have traditionally involved malware, which exploits vulnerabilities in the operating system kernel or in applications, such as the Internet Explorer browser, or, more recently, vulnerabilities in common plug-ins such as the Adobe Acrobat Reader, Flash or Java and JavaScript. They typically have been lower-level-type exploits of bugs in the system.
On mobile, we're seeing less of that because the operating systems, in particular iOS and Android, are generally newer operating systems with a stronger security model than broader legacy operating systems like Windows. The threats are different and the threats that we've been seeing include what we would call malicious applications - not malware in the way that we're used to it on Windows, but applications that users are tricked into willfully and purposefully downloading.
An example would be there were versions of the game Angry Birds, which costs money to purchase. There are now versions of those that have been taken, hacked and malicious code's been added to them. They're posted for free on off-shore marketplaces where people can easily find them and they willfully download them, unaware that it's not the real version of Angry Birds.
We've also seen what we call SMS stealer applications that get onto the user's device and will intercept SMS messages that may be sent to them from their bank or increasingly from other online services as a form of two-factor authentication or transaction authentication. We've also seen network-level attacks primarily at the Wi-Fi level, or behind the Wi-Fi and the DNS, either at the Wi-Fi or at the ISP, and those include poisoning or takeover of the DNS inside of hotspots that have the default admin password. Those are attacks not just at the device, but actually at the Wi-Fi hotspots that everybody is using these devices to connect through. Those are some of the new types of attacks we're seeing against mobile users.

Mobile Threat Research

KITTEN: The APWG recently issued a report about some of these emerging threats. What are some of the highlights from that report?
JEVANS: The big message here as you look through the report and the final conclusion is that malicious and fraudulent activity on the mobile platform is growing much more quickly and will continue to grow much more quickly than it did on the PC platform over the last 10 years. The reason is because over 10 years of cybercrime, the underground has been created all around the world. It's composed of people who write phishing kits, people who write malware, people who have zero-day exploits, people who know how to push them out, spammers, and these people who run what we call bulletproof hosting where you can host these malicious apps and malware and you can't get them taken down. The fraud on the back-end - how they monetize, how they use mules to move money around the world - that infrastructure took 10 years to build. That is in place today and they have now figured out that everybody is moving on to the mobile platform, and that whole criminal underground is moving to monetize the mobile platform.
The other takeaway is that there are going to be new types of threats that are going to come after devices as they start implementing NFC payments using your mobile phone. That's going to be truly big dollars in transactions in the future. Your phone is your wallet, and they're fine-tuning their infrastructure to start waiting for that to be able to be exploited. We can expect large-scale attacks of exploit against these devices through these fake applications and that sort of thing as the phones become ... payment instruments.
The other thing that we've got in the report, in addition to a number of technical descriptions and examinations of specific exploits and specific malicious apps, is by working inside of the criminal underground, we've got a snapshot from this year, from the end of Q1, that looks at the different tool kits and services for malicious fraud and attacks against mobile devices and the pricing. What is the criminal underground selling these services and tools for? That's also an interesting glimpse into what we're up against.

Authentication Challenges

KITTEN: I'm also curious about the authentication piece. Is there some concern there about some of the authentication challenges or areas that may be vulnerable when it comes to mobile banking?
JEVANS: Yes. We do look at a number of the authentication challenges and attacks against authentication mechanisms. This breaks down into a couple of areas. One of them is the widespread use of SMS, or application-based messaging, as a second factor of authentication for regular PC-based banking. That's being regularly exploited. We have now seen tool kits ... which allow you to build your own branded app to basically intercept SMS authentication messages sent to phones and trick people into downloading that banking app, but it actually sits as a man-in-the-middle and intercepts those and allows attackers to get those transactions and authentication credentials and log in as you in real-time. Those are some of the things we've looked at.
There's also the threat that a user is on a jail-broken or rooted phone, which basically means if the mobile-banking app on that phone or tablet is not checking to see if the device is rooted or jail-broken, then all bets are off on authentication because the phone will have absolutely no security if it's jail-broken or rooted. That's something that's a great concern when you're opening up mobile banking with the ability to perform transactions. Doing transactions on mobile is increasingly under demand. It's demanded from users, but not just at the consumer level; also wholesale banking, CFOs and finance people want to use tablets to authorize payments. That's definitely a real concern for us.
Lastly, people are worried about, "How do I authenticate a user on a device, at the mobile device, but the SMS doesn't actually do anything?" Our belief is it actually does work as two-factor [authentication], at least through to that device. On an iPad or an Android pad it's a little different, so there are some challenges still to be worked out there.

Concern for Other Sectors

KITTEN: There's an obvious challenge for banking, but are there other sectors that should be concerned about some of these emerging mobile threats?
JEVANS: Anybody who's allowing employees to bring their own devices, in particular these mobile devices, into the workplace or to connect from them to internal workplace applications - whether it's ... the payment system, any form of intellectual property, even SharePoint - or who are allowing employees to use those to connect to third-party cloud services that they might be using, like Salesforce.com or Google Apps, needs to be concerned about the issues around detecting jail-broken, rooted phones and malicious apps on the user's phone.
I'll give you an example. There are some apps out there that, while not specifically malware, will leak corporate information, and this is applicable to banks and any other company. Think of a user on their own tablet and they've got an app that uploads the entire address book to a server out in the cloud. That address book may include all of the addresses of everyone in your corporate directory: their name, e-mail address, phone number and job title perhaps. That information is now being uploaded by one of your users out into some cloud. Whether it's malicious or not, that information is now out there with no control by IT, and that's perfect fodder for spear-phishing back inside the company.

Mobile Platform Vulnerabilities

KITTEN: Is there one type of mobile platform that you would deem to be more vulnerable than another?
JEVANS: In general, what we have seen is that the users of the Android platform are more at risk than users of the iOS platform - the Apple platform - or the BlackBerry platform. This is not to say that Android is an inferior technology, because it isn't. But Android and Google have a very open policy to the operating system and to the apps that can run on it, whereas BlackBerry is a very closed system and the Apple system is quite closed. They do have an app store, but effectively, unless your phone is jail-broken, you're only downloading apps from the app store or a corporate app store, and so there's much more security control around those apps.
When we look at Android, the reason that we're seeing 95 percent of the successful attacks and malicious apps being published for Android is there are thousands of different versions of the Android operating system. With Apple, there's only the current version and the previous ones and they're all controlled and issued by the vendor, by Apple. The Android platform is open-source. It's open. The last time I checked, there were over 6,300 different variants of Android that had shipped. That means there are a lot of versions for patching; those also can be configured by the vendors, so there could be lots of security issues with different versions.
The other reason that we see a lot of attacks against users of Android is that it's very easy to download apps from places other than the Android Play marketplace. In fact, there are companies like Amazon who are creating alternate marketplaces, commercial marketplaces, so users are encouraged and in fact want to use other marketplaces. We've seen over 20 different marketplaces - some legit, some full of pirate-ware and malware for the Android platform. It's not that the platform itself is any less secure; it's how it's configured and how open it is.

International Markets at Risk

KITTEN: Are there certain international markets that are at greater risk than others?
JEVANS: Yes. We have seen that in the current form, the European market appears to have a much more aggressive and developed set of attackers that are going after users of mobile devices than in the United States, Canada, etc. The reason for that is that mobile devices and mobile banking have become much more prevalent in Europe than in the United States much more quickly. People have been on those platforms for a long time. Also, two-factor authentication, even at the consumer level, has been far more widespread in Europe than it has in the United States. And, in many cases, they have been using the mobile phone with SMS or apps. The so-called TAN - Transaction Authentication Number - has been used for many years in Europe. The criminals have flocked to the European banking market. However, it doesn't mean that it's necessarily more or less risky because the exact same technical infrastructure is in both different continents so we can expect that they will be taking their wares, if you will, and moving it more aggressively into the American market.
KITTEN: Before we close, are there any final thoughts that you'd like to share about the APWG's report or mobile concerns generally?
JEVANS: I would encourage folks to take a look at both of the mobile reports. One of them looks at the cybercrime underground: the infrastructure; the pricing model; effectively what we're up against; how sophisticated it is and where the new threat vectors are coming from. The second report, more for pure IT security professionals, goes through an analysis of many different malicious applications, malicious social networks, supporting infrastructures, SMS stealers, phishing, sniffing and hosting providers. There are two accompanying reports on mobile security. I encourage people to look at them.
The last thing I'll say is that many people thought the days of effective phishing were somewhat behind us. Phishing still continues at some of the highest levels we've ever seen it, but the effectiveness has gone down as people have been educated and filters have gone in place. What we have seen, though, is that phishing and, in particular, spear-phishing - targeted phishing against the individual - is far more effective when the individuals are using mobile devices than when they're using PCs. We have a whole new set of things to be concerned about.
I'll finish by saying that mobile banking apps are great. They're flourishing. However, many of the developers of mobile banking apps are not security experts, and I encourage banks that are deploying mobile banking apps to go to the trouble of having a third-party analyze those apps. Do penetration testing and check to make sure that security certificate validation inside SSL, things of that nature, are actually implemented correctly. You can get copies of the report at www.apwg.org under the resources section; look for the Mobile Working Group.

750 million mobile phones could be hacked in one minute

https://srlabs.de/

http://happyhacker.org/gtmhh/codebreakera.shtml


Up to 750 million mobile phones around the world carry SIM cards that contain a programming flaw that could leave their owners vulnerable to fraud. The bug allows a hacker to remotely access personal data and authorise illegal transactions within minutes.
The UN’s International Telecommunications Union is to send an alert to all mobile phone operators after being presented with “hugely significant” evidence of a design flaw by renowned German code-breaker Karsten Nohl.
The bug affects the SIM card, the plastic circuit board that contains key phone user data, which is considered to be the most-secure part of the phone, and has not been hacked in a similar fashion in a decade. By finding out the unique encryption key of each SIM card with just one hidden text message, Nohl is able to get complete remote control of an individual’s phone.
"We become the SIM card. We can do anything the normal phone users can do," Nohl told Reuters. "If you have a MasterCard number or PayPal data on the phone, we get that too."
The flaw can be exploited both for financial fraud and for surveillance.
“We can remotely install software on a handset that operates completely independently from your phone. We can spy on you. We know your encryption keys for calls. We can read your texts. More than just spying, we can steal data from the SIM card, your mobile identity, and charge to your account,” Nohl explained to the New York Times.
The 31-year-old 'ethical hacker' Karsten Nohl breaks into secure systems, exploiting their vulnerabilities, and then presents his findings to companies, hoping they fix any issues before they are identified by criminals.
'Ethical hacker' Karsten Nohl
'Ethical hacker' Karsten Nohl

Nohl says his team had been unsuccessfully attempting to breach SIM cards since 2011, using over-the-air-programming (OTA) – unseen text messages that are sent by the mobile phone operator to change settings on the phone of a user within their network.
“We had almost given up on the idea of breaking the most widely-deployed use of standard cryptography,”admitted Nohl, who says that SIM card tampering is the 'Holy Grail' for any hacker.
In the end, the flaw was found by accident.
Nohl noticed that when he attempted to send certain incorrect OTA commands, he would receive an error message that also contained the unique encryption code belonging to that phone – its virtual key. The code was easily decrypted – Nohl says the process takes him one minute. With the phone now at his disposal, he could command it to do anything from his own computer, without the user ever suspecting anything was amiss.
The bug was not found in every SIM card tested - Nohl researched more than a thousand - but he estimates that it is present in about a quarter of SIM cards using Data Encryption Standard (DES), a security standard that is being phased out but is still used on about 3 billion active phones. That’s why Nohl estimates that 750 million users might be in danger. What’s more, there is no easy way for a DES SIM card owner to identify if their phone is susceptible.
The security expert has already privately informed authorities about his findings through a process called 'responsible disclosure', and believes it will take hackers six months to repeat his feat, giving manufacturers a head start.  Nohl will detail his break-in at a Black Hat, a hackers conference that begins in Las Vegas at the end of July.
While leading companies have released statements acknowledging the flaw, and saying that they are working to eradicate it, authorities have urged calm among ordinary users, noting that no criminal damage appears to have been done so far.
"This is not what hackers are focused on. This does not seem to be something they are exploiting,"reassured John Marinho, Vice President of Technology and Cybersecurity at CTIA, the leading US mobile industry group.
But whatever the immediate risks, the UN is less sanguine.
"These findings show us where we could be heading in terms of cyber-security risks," ITU Secretary-General Hamadoun Touré told Reuters.