dw2

29 April 2012

My brief skirmish with Android malware

Filed under: Android, deception, malware, security — David Wood @ 2:19 pm

The smartphone security issue is going to run and run. There’s an escalating arms race, between would-be breakers of security and would-be defenders. The race involves both technology engineering and social engineering.

There is a lot at stake:

  • The numbers of users of smartphones continues to rise
  • The amount of sensitive data carried by a typical user on their smartphone (or accessible via credentials on their smartphone) continues to rise
  • Users increasingly become accustomed to the idea of downloading and installing applications on their mobile devices
  • Larger numbers of people turn their minds to crafting ways to persuade users to install apps against their better interest – apps that surreptitiously siphon off data and/or payments

In that context, I offer the following cautionary tale.

This afternoon, I unexpectedly ran into an example of this security arm race. I was minding my own business, doing what lots of people are doing in the UK these days – checking the weather forecast.

My Samsung Galaxy Note, which runs Android, came with an AccuWeather widget pre-installed on the default homescreen:

Clicking on the widget brings up a larger screen, with more content:

Clicking the ‘More’ button opens a web-browser, positioned to a subpage of m.accuweather.com.  I browsed a few screens of different weather information, and then noticed an inviting message near the bottom of the screen:

  • Turbo Battery Boost – Android System Update

I was curious, and decided to see where that link would lead.  On first glance, it appeared to take me into the Android Marketplace:

The reviews looked positive. Nearly two million downloads, with average rating around 4.5 stars. As someone who finds I need to recharge the battery in my Android midway every day, I could see the attraction of the application.

As I was weighing up what to do next, another alert popped up on the screen:

By this stage, I was fairly sure that something fishy was going on. I felt sure that, if there really was a breakthrough in battery management software for Android, I would have heard about it via other means. But by now I was intrigued, so I decided to play along for a while, to see how the story unfolded.

Clicking ‘Next’ immediately started downloading the app:

which was immediately followed by more advice on what I should do next, including the instruction to configure Android to accept updates from outside the Android Market:

Sure enough, the notifications area now contained a downloaded APK file, temptingly labelled “tap to start”:

A risk-averse person would probably have stopped at that point, fearful of what damage the suspicious-looking APK might wreak on my phone. But I had enough confidence in the Android installation gateway to risk one more click:

That’s a heck of a lot of permissions, but it’s nothing unusual. Many of the other apps I’ve installed recently have requested what seemed like a similar range of permissions. The difference in this case was that I reasoned that I had little trust in the origin of this latest application.

Even though the initial ad had been served up on the website of a reputable company, AccuWeather, and implied some kind of endorsement from AccuWeather for this application, I doubted that any such careful endorsement had taken place. Probably the connection via the AccuWeather webpage and the ads shown in it is via some indirect broker.

Anyway, I typed “Android BatteryUpgrade” into a Google search bar, and quickly found various horror stories.

For example, from a PCWorld article by Tom Spring, “Sleazy Ads on Android Devices Push Bogus ‘Battery Upgrade’ Warnings“:

Sketchy ads promote battery-saver apps for Android, but security experts say the programs are really designed to steal your data–or your money

Scareware has gone mobile: Users of Android devices are starting to see sleazy ads warning that they need to upgrade their device’s battery. The supposed battery-saver apps that those ads prod you to download, however, could endanger your privacy or siphon money from your wallet–and generally they’ll do nothing to improve your gadget’s battery life…

“These ads cross a line,” says Andrew Brandt, director of threat research for Solera Networks. It’s one thing to market a worthless battery app, he says, but another to scare or trick people into installing a program they don’t need.

The ads are similar to scareware marketing tactics that have appeared on PCs: Such ads pop up on desktops or laptops, warning that your computer is infected and advising you to download a program to fix the problem. In many cases those rogue system utilities and antivirus products are merely disguises for software that spies on users.

Why use battery ads as a ploy? They tap into a common anxiety, Brandt says. Phone users aren’t yet concerned about viruses on their phones, but they are worried about their battery being sucked dry.

Brandt says that one Android battery app, called both Battery Doctor and Battery Upgrade, is particularly problematic: Not only does it not upgrade a battery or extend a charge, but when it’s installed and unlocked, it harvests the phone’s address book, the phone number, the user’s name and email address, and the phone’s unique identifying IMEI number. With a phone user’s name, IMEI, and wireless account information, an attacker could clone the phone and intercept calls and SMS messages, or siphon money from a user by initiating premium calls and SMS services. Once the battery app is installed the program sends the phone ads that appear in the drop down status bar of the phone at all times – whether the app is running or not. Lastly it periodically transmits changes to the user’s private information and phone-hardware details to its servers…

Now on the one hand, Android deserves praise for pointing out to the user (me, in this case) that the application was requesting lots of powerful capabilities. On the other hand, it’s likely that at least some users would just think, “click, click, yes I really do want to install this, click, click”, having been desensitised to the issue by having installed lots of other apps in seemingly similar ways in the past.

Buyer beware. Especially if the cost is zero – and if the origin of the application cannot be trusted.

Footnote: Now that I’m paying more attention, I can see lots of other “sleazy” (yes, that’s probably the right word) advertisements on AccuWeather’s mobile webpages.

8 May 2011

Future technology: merger or trainwreck?

Filed under: AGI, computer science, futurist, Humanity Plus, Kurzweil, malware, Moore's Law, Singularity — David Wood @ 1:35 pm

Imagine.  You’ve been working for many decades, benefiting from advances in computing.  The near miracles of modern spreadsheets, Internet search engines, collaborative online encyclopaedias, pattern recognition systems, dynamic 3D maps, instant language translation tools, recommendation engines, immersive video communications, and so on, have been steadily making you smarter and increasing your effectiveness.  You  look forward to continuing to “merge” your native biological intelligence with the creations of technology.  But then … bang!

Suddenly, much faster than we expected, a new breed of artificial intelligence is bearing down on us, like a huge intercity train rushing forward at several hundred kilometres per hour.  Is this the kind of thing you can easily hop onto, and incorporate in our own evolution?  Care to stand in front of this train, sticking out your thumb to try to hitch a lift?

This image comes from a profound set of slides used by Jaan Tallinn, one of the programmers behind Kazaa and a founding engineer of Skype.  Jaan was speaking last month at the Humanity+ UK event which reviewed the film “Transcendent Man” – the film made by director Barry Ptolemy about the ideas and projects of serial inventor and radical futurist Ray Kurzweil.  You can find a video of Jaan’s slides on blip.tv, and videos (but with weaker audio) of talks by all five panelists on KoanPhilosopher’s YouTube channel.

Jaan was commenting on a view that was expressed again and again in the Kurzweil film – the view that humans and computers/robots will be able to merge, into some kind of hybrid “post-human”:

This “merger” viewpoint has a lot of attractions:

  • It builds on the observation that we have long co-existed with the products of technology – such as clothing, jewellery, watches, spectacles, heart pacemakers, artificial hips, cochlear implants, and so on
  • It provides a reassuring answer to the view that computers will one day be much smarter than (unmodified) humans, and that robots will be much stronger than (unmodified) humans.

But this kind of merger presupposes that the pace of improvement in AI algorithms will remain slow enough that we humans can remain in charge.  In short, it presupposes what people call a “soft take-off” for super-AI, rather than a sudden “hard take-off”.  In his presentation, Jaan offered three arguments in favour of a possible hard take-off.

The first argument is a counter to a counter.  The counter-argument, made by various critics of the concept of the singularity, is that Kurzweil’s views on the emergence of super-AI depend on the continuation of exponential curves of technological progress.  Since few people believe that these exponential curves really will continue indefinitely, the whole argument is suspect.  The counter to the counter is that the emergence of super-AI makes no assumption about the shape of the curve of progress.  It just depends upon technology eventually reaching a particular point – namely, the point where computers are better than humans at writing software.  Once that happens, all bets are off.

The second argument is that getting the right algorithm can make a tremendous difference.  Computer performance isn’t just dependent on improved hardware.  It can, equally, be critically dependent upon finding the right algorithms.  And sometimes the emergence of the right algorithm takes the world by surprise.  Here, Jaan gave the example of the unforeseen announcement in 1993 by mathematician Andrew Wiles of a proof of the centuries-old Fermat’s Last Theorem.  What Andrew Wiles did for the venerable problem of Fermat’s last theorem, another researcher might do for the even more venerable problem of superhuman AI.

The third argument is that AI researchers are already sitting on what can be called a huge “hardware overhang”:

As Jaan states:

It’s important to note that with every year the AI algorithm remains unsolved, the hardware marches to the beat of Moore’s Law – creating a massive hardware overhang.  The first AI is likely to find itself running on a computer that’s several orders of magnitude faster than needed for human level intelligence.  Not to mention that it will find an Internet worth of computers to take over and retool for its purpose.

Imagine.  The worst set of malware so far created – exploiting a combination of security vulnerabilities, other software defects, and social engineering.  How quickly that can spread around the Internet.  Now imagine an author of that malware that is 100 times smarter.  Human users will find themselves almost unable to resist clicking on tempting links and unthinkingly providing passwords to screens that look identical to the ones they were half-expecting to see.  Vast computing resources will quickly become available to the rapidly evolving, intensely self-improving algorithms.  It will be the mother of all botnets, ruthlessly pursing whatever are the (probably unforeseen) logical conclusions of the software that gave it birth.

OK, so the risk of hard take-off is very difficult to estimate.  At the H+UK meeting, the panelists all expressed significant uncertainty about their predictions for the future.  But that’s not a reason for inaction.  If we thought the risk of super-AI hard take-off in the next 20 years was only 5%, that would still merit deep thought from us.  (Would you get on an airplane if you were told the risk of it plummeting out of the sky was 5%?)

I’ll end with another potential comparison, which I’ve written about before.  It’s another example about underestimating the effects of breakthrough new technology.

On 1st March 1954, the US military performed their first test of a dry fuel hydrogen bomb, at the Bikini Atoll in the Marshall Islands.  The explosive yield was expected to be from 4 to 6 Megatons.  But when the device was exploded, the yield was 15 Megatons, two and a half times the expected maximum.  As the Wikipedia article on this test explosion explains:

The cause of the high yield was a laboratory error made by designers of the device at Los Alamos National Laboratory.  They considered only the lithium-6 isotope in the lithium deuteride secondary to be reactive; the lithium-7 isotope, accounting for 60% of the lithium content, was assumed to be inert…

Contrary to expectations, when the lithium-7 isotope is bombarded with high-energy neutrons, it absorbs a neutron then decomposes to form an alpha particle, another neutron, and a tritium nucleus.  This means that much more tritium was produced than expected, and the extra tritium in fusion with deuterium (as well as the extra neutron from lithium-7 decomposition) produced many more neutrons than expected, causing far more fissioning of the uranium tamper, thus increasing yield.

This resultant extra fuel (both lithium-6 and lithium-7) contributed greatly to the fusion reactions and neutron production and in this manner greatly increased the device’s explosive output.

Sadly, this calculation error resulted in much more radioactive fallout than anticipated.  Many of the crew in a nearby Japanese fishing boat, the Lucky Dragon No. 5, became ill in the wake of direct contact with the fallout.  One of the crew subsequently died from the illness – the first human casualty from thermonuclear weapons.

Suppose the error in calculation had been significantly worse – perhaps by an order of thousands rather than by a factor of 2.5.  This might seem unlikely, but when we deal with powerful unknowns, we cannot rule out powerful unforeseen consequences.  For example, imagine if extreme human activity somehow interfered with the incompletely understood mechanisms governing supervolcanoes – such as the one that exploded around 73,000 years ago at Lake Toba (Sumatra, Indonesia) and which is thought to have reduced the worldwide human population at the time to perhaps as few as several thousand people.

The more quickly things change, the harder it is to foresee and monitor all the consequences.  The more powerful our technology becomes, the more drastic the unintended consequences become.  Merger or trainwreck?  I believe the outcome is still wide open.

7 July 2008

Symbian signed and openness

Filed under: malware, openness, Symbian Foundation, Symbian Signed — David Wood @ 8:13 pm

The team at Telco2.0 have run some good conferences, and there’s much to applaud in their Manifesto. Recently, the Telco2.0 blog has run a couple of hit-and-miss pieces of analysis on the Symbian Foundation. There’s a lot of speculation in their pieces, and alas, their imagination has run a bit wild. The second of these pieces, in particular, is more “miss” than “hit”. Entitled “Symbian goes open – or does it?”, the piece goes most clearly off the rails when it starts speculating about Symbian Signed:

…the Symbian signing process doesn’t just apply to changes to Symbian itself — it applies to all applications developed for use on Symbian, at least ones that want to use a list of capabilities that can be summed up as “everything interesting or useful”. I can’t even sign code for my own personal use if it requires, say, SMS functionality. And this also affects work in other governance regimes. So if I write a Python program, which knows no such thing as code-signing and is entirely free, I can’t run it on an S60 device without submitting to Symbian’s scrutiny and gatekeeping. And you though Microsoft was an evil operating system monopolist…

This makes the Symbian signing process sound awful. But wait a minute. Isn’t there a popular book, “Mobile Python – rapid prototyping of applications on the mobile platform“, written by Jurgen Scheible and Ville Tuulos, that highlights on the contrary just how simple it is to get going with sophisticated Python applications on S60 devices? Yep. And what do we find as early as page 45 of the book? A two-line program that sends an SMS message:

import messaging
messaging.sms_send(“+14874323981″, u”Greetings from PyS60”)

I tried it. It took less than an hour to download and install the SIS files for the latest version of PyS60 from Sourceforge, and then to type in and run this program. (Of course, you change the phone number before testing the app.) Nowhere in the process is there any submitting of the newly written program “to Symbian’s scrutiny and gatekeeping”. The fanciful claims of the Telco2.0 piece are refuted in just two lines of Python.

So what’s really going on here? How is it that normally intelligent analysts and developers often commit schoolboy howlers when they start writing about Symbian Signed? (Unfortunately, the Telco2.0 writers are by no means unique in getting the Symbian Signed facts wrong.) And why, when people encounter glitches or frustrations in the implementation of Symbian Signed, are they often too ready to criticise the whole system, rather than being willing to ask what small thing they might do differently, to get things working again?

I suspect three broader factors are at work:

1. An over-casual approach to the threat of mobile malware

Symbian Signed is part of an overall system that significantly reduces the threat of mobile viruses and the like. Some developers or analysts sometimes give the impression that they think they stand immune from malware – that it’s only a problem that impacts lesser mortals, and that the whole anti-malware industry is a “cure that’s worse than the disease”. Occasionally I sympathise with this view, when I’m waiting for my desktop PC to become responsive, with its CPU cycles seemingly being consumed by excessive scanning and checking for malware. But then I remember the horrors that ensue if the defences are breached – and I remember that the disease is actually worse than the cure.

If we in the mobile industry take our eye off the security ball and allow malware to take root in mobile phones in ways similar to the sad circumstances of desktop PCs, it could produce a meltdown scenario in which end users decide in droves that the extra intelligence of smart mobile phones brings much more trouble than it’s worth. And smartphones would remain of only niche interest. For these reasons, at least the basic principles of Symbian Signed surely deserve support.

2. A distrust of the motivation of network operators or phone manufacturers

The second factor at work is a distrust of control points in the allocation of approvals for applications to have specific capabilities. People reason something like this:

  • OK, maybe some kind of testing or approvals process does makes sense
  • But I don’t trust Entity-X to do the approving – they have mixed motivations.

Entity-X could be a network operator, that may fear losing (for example) their own SMS revenues if alternative IM applications were widely installed on their phones. Or Entity-X could be a device manufacturer, like Apple, that might decide to withhold approval from third party iPhone applications that provide download music stores to compete with iTunes.

Yes, there’s a potential risk here. But there are two possible approaches to this risk:

  1. Decide that there’s no possible solution, and therefore the power of a system like Symbian Signed should be criticised and diminished
  2. Work to support more of the decision making happening in a fully transparent and independent way, outside of the influence of mixed motivations.

The second approach is what’s happening with the Symbian Foundation. The intent with the Symbian Foundation is to push into the public sphere, not only more and more of the source code of the Symbian Platform, but also as much of the decision-making as possible – including the rules and processes for approval for Symbian Signing.

Incidentally, the likely real-world alternative to a single, unified scheme for reviewing and signing applications is that there will be lots of separately run, conflicting, fragmented signing schemes. That would be a BAD outcome.

3. A belief that openness trumps security

This brings us to the final factor. I suspect that people reason as follows:

  • OK, I see the arguments for security, and (perhaps) for quality assurance of applications
  • But Symbian Signed puts an obstacle in the way of openness, and that’s a worse outcome
  • Openness is the paramount virtue, and needs to win.

As a great fan of openness, I find myself tempted by this argument from time to time. But it’s a misleading argument. Instead, freedom depends on a certain stability in the environment (including a police force and environmental inspectors). Likewise, openness depends on a basic stability and reliability in the network, in the underlying software, and in the way the ecosystem operates. Take away these environmental stability factors, and you’ll lose the ability to meaningfully create innovative new software.

The intention behind Symbian Signed to help maintain the confidence of the industry in the potential of smartphones – confidence that smartphones will deliver increasing benefits without requiring debilitating amounts of support or maintenance.

It’s true that the rules of Symbian Signed can take a bit of learning. But hey, lots of other vital pieces of social or technical infrastructure likewise take time to appreciate. In my mind, the effort is well worth it: I see Symbian Signed as part of the bedrock of meaningful openness, instead of some kind of obstacle.

Blog at WordPress.com.