Until now, Google hasn’t talked about malware on Android because it did not have the data or analytic platform to back its security claims. But that changed dramatically today when Google’s Android Security chief Adrian Ludwig reported data showing that less than an estimated 0.001% of app installations on Android are able to evade the system’s multi-layered defenses and cause harm to users. Android, built on an open innovation model, has quietly resisted the locked down, total control model spawned by decades of Windows malware. Ludwig spoke today at the Virus Bulletin conference in Berlin because he has the data to dispute the claims of pervasive Android malware threats.
Like, for instance, this?
That's a real attempt from a real app in the real Play Store that really did ask for my permission to, well, do anything. And it's recent too -- just a couple of weeks back.
No, I didn't say "yes."
And saying "yes" is giving permission to breach many of the so-called "walls" that are cited in that link -- with your permission, not by some trick-of-the-code that "breaks in."
I might have said yes, incidentally, if I hadn't been damned suspicious because I knew the app was bull****. It was in fact a claimed BBM client for Android, which was in the Play Store (and which reappeared multiple times despite being deleted multiple times, presumably by Google) while BlackBerry was recently in the process of attempting to roll out it's actual and real client.
There were, in fact many such fake clients on Play Store:
Now I didn't get ****ed, but I didn't say "Yes." And as such I'm not really sure what was in that app. I have the tools here to deconstruct an application and look at it, but in order to do that I have to load it first, and that means I had to say "Yes."
Since one of the permissions the app wanted was to be able to autostart, and another was to be able to edit shortcuts, there was no guarantee that it wouldn't immediately rename and try to hide itself.
In other words once I said "Yes" I was committed to firmware flashing the device in question to be sure I really had deleted whatever I downloaded, which happens to be my Android tablet -- a device I was unwilling to intentionally brick (and re-flash via ODIN) for this purpose.
Even a hard reset is not necessarily good enough, if the app in question has figured out how to break out of the sandbox -- and it might have. In that case it could conceivable mount the system partition for write, and if that happens even a "hard reset" won't get rid of it.
In other words if you downloaded something like this and let it install the only way to know you're safe is to overwrite all of the flash memory in the device, effectively "reformatting" it.
For Android devices this is not typically possible for the ordinary, non-techie-oriented user as a "hard reset" only erases the user data partition -- it does not overwrite the system partition. If anything has managed to modify that partition (for good or bad) it remains as it was even after a hard reset.
Google may claim "innovation" in this regard, but before you buy that claim I direct you to the install screen where it asked for these permissions. Note the "Hide" tab.
I expanded that -- by default none of those permissions under the "Hide" tab were visible to me, and those are the nasty ones.
In fact, for a messenger client the permissions that are above the "Hide" tab look pretty reasonable. Only the last one might be unreasonable -- being able to look at and change browser information. But then again maybe not: In this integrated world where being able to bookmark things looks pretty reasonable on-balance to most people.
So why is there that second, "must press to expand" category? Why is it not true that when you try to install an application that wants any of those bottom permissions you're not warned quite-explicitly that the application is asking for account information for other accounts you have signed into, access to protected storage, and access to make itself persistent, uninstall and change the apparent installed apps on the device and close other applications potentially including any security software you may have on the unit?
Hiding that by default and expecting people to push a button to see it rather than screaming when an application wants any of these things is so "proactive" when it comes to security...... right?
That's kind of like claiming that Chrome is "very secure" while not telling you if perfect forward secrecy is enabled unless you go look specifically (and know how) -- while most "secure" web servers around the net have it disabled on purpose.
Oh wait, that's not a contrived example either -- Chrome (and the rest of the browsers!) do that too.
I'd take Google's claims a lot more seriously in this regard if any attempt to install using those "below the line" permissions popped up a very explicit warning for each, and required your specific approval for each, without you having to "drill down" to even see that they were requested.
But as things stand today that's not how Android works.
As noted in the first comment, let me guess -- Android's people would not call that app "malware" as it actually asked for all the permissions it got and then used -- right?
You, of course, might see it a bit differently.
Just because this is a big-ass block of salt that should be rubbed into the eyes of the banksters and other commercial sites.
There are ads displayed on the top page of Tickerforum, which is why you get the "there are other resources that are not secure" warning. But note the bottom block -- ECDHE_RSA is a Perfect Forward Secrecy negotiated key exchange.
While this is not easily-decipherable by the common man what it means is that if you steal the private key you cannot retrospectively decode any saved encrypted session using it. You can step in the middle of the transmission and intercept what I do in the future, but you are NOT helped with previous transmissions you might have recorded in encrypted form.
Now let's look at a few other sites around the net... including some important ones.
Do you bank with Bank of Scamerica? Oh good, because any so-called "encrypted" sessions with them can be retrospectively decrypted if their private key is compromised. And we know the NSA has never "asked" for their private key because nobody has ever done a bad thing using Bank of America, right?
Do you believe in Santa Claus?
Schwab is even "better"! Not only does Schwab not allow PFS and thus any session with them can be retrospectively decrypted but they use MD5 for message authentication -- which is quite-breakable. Thanks a lot guys.
How about one of the favorites, Interactive Brokers?
Thank you for trading with the NSA; your options and futures positions have been dutifully recorded and will be retrospectively decrypted whenever we feel like it.
How about Fidelity?
**** you very little, Fidelity.
Jamie Dimon is also happy to present your so-called "encrypted" data in a form and fashion that allows perfect retrospective decryption.
And again I'm absolutely certain that JP Morgan/Chase has never had a "bad guy" use their services, and thus they would never have been "asked" for their secret key.
How about something more-mundane? Microsoft's Office365. After all, the cloud is a good place to store all your secure business documents, like, for instance, legal documents -- right?
All retrospectively decryptable, provided the NSA has the secret key. Once again, you believe that there has never been a bad guy on Microsoft's "secure" services that would prompt a demand for a secret key (and that Microsoft would refuse to turn it over if "asked"), right? Never?
Do you use Bitcon to transact? Might you use Mtgox? Everything you do -- or ever did -- through them is retrospectively decryptable. Thank you very little, *******s.
There are some good guys though among "large" commercial sites. One of them is Twitter.
I'll be damned.
Finally, you know the government would always protect your data, right? Especially when you're signing up for health insurance under Obamacare. And particularly given that this is a brand new thing, and thus the old "we always did it the other way" isn't an excuse!
**** you Mr. President.
And here's a giant "**** You" to all the browser writers. Firefox, Internet Explorer and Safari all make it nearly impossible to determine if PFS is enabled or not. Opera and Chrome expose the data but do not explain what it means.
None of the browser writers do something like turn the SSL box "green" as they do for so-called "Extended Validation" certificates, which allegedly is "more secure" than a "standard" certificate.
Yet whether or not the connection has PFS enabled is far more important in terms of "hackability" than whether or not a site has an "Extended Validation" certificate!
Again, if you're not using a "prefixed" key exchange mechanism any encrypted session that is stored can be retrospectively decrypted at any time in the future should the secret key be compromised from the remote end, and that is never under your control.
Further, when these jackasses come knocking at some web server's site (or the owner of a "cloud" service you bought space on) 99.9% of the time the target will be served with a gag order and most targets will neither fight or do anything to tell you about it or mitigate these risks (such as changing the secret key.)
Finally, the odds of any large business having never had a "bad guy" on their network that might "attract" such a demand are zero.
In today's world where CPU cycles are quite cheap there is utterly no excuse, other than intentionally exposing your traffic to retrospective decryption, for a site to not enable PFS.
The feds have caught up to the Silk Road. The underground website long known for drug trafficking and other illegal activity was seized by the FBI who also arrested the owner on three criminal counts. New York State prosecutors charged Ross William Ulbricht with one count each of narcotics trafficking conspiracy, computer hacking conspiracy and money laundering conspiracy, according to a court filing.
YBF, or, if you want English, "You Be ****ed."
That sort of set of conspiracy charges are good for a "bye-bye" if convicted, and I predict he will be.
The cops apparently made over 100 "buys" through the site for various illegal drugs.
Setting aside the question as to whether the drugs should be illegal, the fact is that they are and under current law the penalty is what it is, never mind the money-laundering allegations which are an entirely-different (but equally ugly) kettle of fish.
There are plenty of people who think that "TOR" somehow makes them untraceable. Wrong. As I have repeatedly pointed out it probably is good enough against a web site owner who wants to know who you are.
But since there are relatively few high-traffic nodes the points you must compromise in order to be able to eventually figure out both ends of a flow are reasonably small, and thus a government that wants to find out who you are is going to.
And here, folks, is your object lesson.
PS: Since they seized the computer they also now have a nice list of all the transactions, and probably the Bitcoin crypto hashes for them. Bitcoin purchases are not anonymous -- they in fact are forever memorialized in the block chain, which means that one mistake (made by you or the person you do "business" with) and your transaction is indelibly tied to you via absolute mathematically-provable cryptography -- the very same cryptography that makes Bitcoin work!
The "YBF"s are just beginning on this one folks....
Whether or not there turns out to have been a murder, the part about blackmail is central to any broader discussion of Bitcoin or other virtual currencies. Think about it for a second. The accusation that someone was able to get a list of Bitcoin users at all undermines Bitcoin’s very reason for existence. It highlights how using an ostensibly untraceable currency makes for a lovely invitation to blackmailers.
And to governments. Anyone who imagines that Bitcoin is somehow a refuge from government surveillance has to get a chill reading that in a space of about five and a half months there were “146,946 unique buyer accounts and 3,877 unique seller accounts.” Identify some of those seller accounts and guess what — you’re well on your way to identifying the buyer accounts.
LOS ANGELES – It took just a week for nearly 300 students who got iPads from their Los Angeles high school to figure out how to alter the security settings so they could surf the Web and access social media sites.
So let me see -- we have the school district that thinks they have a "secure" means of using these things to replace textbooks (although they're both expensive and fragile) and this will be a "superior" solution.
The truth is that a handful of kids can break their so-called "security" within days.
Now, the question: What does this say about the so-called "security" that is available on these devices in other, more-hostile environments?
Oh, we can't have that discussion, can we? Certainly not among CIOs and others who are using these things to do stuff like..... manage medical records? Take them into a cockpit with sectionals on it? Or any one of a number of other environments that appear benign (that is, where the users themselves have no particular reason to try to break into them) but others might and the consequences of such a breach are a bit more serious than someone logging into Facebook.
In fact, read it two, three, four, five or however many times you need to until you "get it."
Now here's the ugly little ditty -- on Android you have to take it or leave it when it comes to application permissions. You get one, and only one, shot to say "NO" -- at installation time.
From that point forward all you can do is de-install the app, and if it got permissions sufficient to hide itself you may not really be de-installing it at all, especially if it also got permission to run at boot!
Now let's look at BlackBerry 10.
I'm going to pick on the Facebook app.
This is what it wants "by default":
That's not much -- access to your files (so you can upload pictures and such) and location (so it can "check you in.")
But still, perhaps you don't like that. Note that those are switches, not statements.
So let's turn them off:
Now that might break the app, but you are in charge, not the developer. You have the right to veto access to whatever you don't want the app to have. If it breaks it, it breaks it -- you can always change your mind and turn it back on.
But in this case, it doesn't break it. I know this because I run with these turned off and only turn them on when I want Facebook to have that access (and the ability to disseminate my location) -- which is seldom, but not never.
So let's try to tell it to post something and get our location:
Oops -- no can do, because I told the system to deny Facebook access to my location.
This is how it should be.
You should be in charge.
NOT Google, NOT some application developer and certainly not in a drop-down tab that you might not check and/or understand.
This is one of the defining differences that BlackBerry devices have -- and have always had. Even the older, infirm BB7 devices allowed you to choose what permissions were allowed or not for an application. BB10 carries this forward.
On BlackBerry 10 devices you are in charge.
NOT the developer and NOT BlackBerry.
This is how it should be.
But this is not how it is on Android. Incidentally, if you load Android apps on your BlackBerry, while the permissions those apps request and get at load time are listed you can't shut them off -- because Android is designed to not allow you to.
Isn't that special?
You, the American Sheeple, make choices when you buy things -- or don't buy things. Some of those choices have not-so-obvious consequences.
If BlackBerry disappears one of the choices you will permanently lose is the ability to choose what the applications on your smartphone can access and divulge to others without your knowledge or consent.
Is that a wise thing to lose?
YOU decide, but remember -- if you choose not to decide you still have made a choice.
Where We Are, Where We're Heading (2013) - The annual 2013 Ticker
The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.
NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.
The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.
Looking for "The Best of Market Ticker"? Check out Ticker Classics.
Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.
The Market Ticker content may be reproduced or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media or for commercial use.
Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.