I have been reading about the new Flame (aka Flamer, aka sKyWIper) “supervirus.”

[AAaaaarrrrrrggggghhhh!!!!!!!!  Sorry.  I will try and keep the screaming, in my "outside voice," to a minimum.]

From the Telegraph:

This “virus” [1] is “20 times more powerful” than any other!  [Why?  Because it has 20 times more code?  Because it is running on 20 times more computers?  (It isn't.  If you aren't a sysadmin in the Middle East you basically don't have to worry.)  Because the computers it is running on are 20 times more powerful?  This claim is pointless and ridiculous.]

[I had it right the first time.  The file that is being examined is 20 megabytes.  Sorry, I'm from the old days.  Anybody who needs 20 megs to build a piece of malware isn't a genius.  Tight code is *much* more impressive.  This is just sloppy.]

It “could only have been created by a state.”  [What have you got against those of us who live in provinces?]

“Flame can gather data files, remotely change settings on computers, turn on computer microphones to record conversations, take screen shots and copy instant messaging chats.”  [So?  We had RATs that could do that at least a decade ago.]

“… a Russian security firm that specialises in targeting malicious computer code … made the 20 megabyte virus available to other researchers yesterday claiming it did not fully understand its scope and said its code was 100 times the size of the most malicious software.”  [I rather doubt they made the claim that they didn't understand it.  It would take time to plow through 20 megs of code, so it makes sense to send it around the AV community.  But I still say these "size of code" and "most malicious" statements are useless, to say the least.]

It was “released five years ago and had infected machines in Iran, Israel, Sudan, Syria, Lebanon, Saudi Arabia and Egypt.”  [Five years?  Good grief!  This thing is a pretty wimpy virus!  (Or self-limiting in some way.)  Even in the days of BSIs and sneakernet you could spread something around the world in half a year at most.]

“If Flame went on undiscovered for five years, the only logical conclusion is that there are other operations ongoing that we don’t know about.”  [Yeah.  Like "not reproducing."]

“The file, which infects Microsoft Windows computers, has five encryption algorithms,”  [Gosh!  The best we could do before was a couple of dozen!]  “exotic data storage formats”  [Like "not plain text."]  “and the ability to steal documents, spy on computer users and more.”  [Yawn.]

“Components enable those behind it, who use a network of rapidly-shifting “command and control” servers to direct the virus …”  [Gee!  You mean like a botnet or something?]

Sorry.  Yes, I do know that this is supposed to be (and probably is) state-sponsored, and purposefully written to attack specific targets and evade detection.  I get it.  It will be (marginally) interesting to see what they pull out of the code over the next few years.  It’s even kind of impressive that someone built a RAT that went undetected for that long, even though it was specifically built to hide and move slowly.

But all this “supervirus” nonsense is giving me pains.

[1] First off, everybody is calling it a “virus.”  But many reports say they don’t know how it got where it was found.  Duh!  If it’s a virus, that’s kind of the first issue, isn’t it?

The Department of Homeland Security has been forced to release a list of keywords and phrases it uses to monitor social networking sites and online media.  (Like this one?)

I’ve used Ad-Aware in the past, and had it installed on my machine.  Today it popped up and told me it was out of date.  So, at their suggestion, I updated to the free version, which is now, apparently, called Ad-Aware Free Antivirus+.  It provides for real-time scanning, Web browsing protection, download protection, email protection, and other functions.  Including “superfast” antivirus scanning.  I installed it.

And almost immediately removed it from the machine.

First off, my machine bogged down to an unusable state.  The keyboard and mouse froze frequently, and many programs (including Ad-Aware) were unresponsive for much of the time.  Web browsing became ludicrous.

There are some settings in the application.  For my purposes (as a malware researcher) they were inadequate.  There is an “ignore” list, but I was completely unable to get the program to “ignore” my malware zoo, even after repeated efforts.  (The interface for that function is also bizarrely complex.)  However, I’m kind of a non-typical user.  However, the other options would be of little use to anyone.  For the most part they were of the “on or off” level, and provide almost no granularity.  That makes them simple to use, but useless.

I’ve never used Ad-Aware much, but it’s disappointing to see yet another relatively decent tool “improved” into non-utility.

Hacktivity 2012 Call For Papers: Deadline June 1st

The 9th annual IT Security Festival for Central and Eastern Europe will be held in Hungary in late September. The Hacktivity 2012 conference/festival will bring together information security professionals from all of central Europe in an informal, educational, but highly technical form.

Papers for HACKTIVITY 2012 are now being solicited and we invite you to participate.

For more information see: https://hacktivity.com/en/news/cfp-is-out-hurry-up/

For a list of the 36 presentations done in 2011 see: https://hacktivity.com/en/hacktivity-2011/programs/

Like many other people, I try helping developing countries when I can. So to help boost GDP in Eastern Europe and Africa (or ‘redistribute the wealth’ if you will) here’s a quick tutorial that will help scammers get HSBC customers’ credit card numbers. All the steps below are done by the real HSBC, so you don’t even need to “fool” anyone.

An HSBC customer who has gone through this process before won’t be able to distinguish between you and the real HSBC. Customer that has not been through this process certainly won’t know better anyway. In fact, you can do it to HSBC employees and they won’t know.

All you need is a toll-free number for them to call (feel free to forward it to Nigeria). The nice thing about HSBC is that the process below is identical to how the real HSBC asks customers for information. In other words: HSBC is training their customers to follow this path. I propose a new term for HSBC’s method of breeding phish: spowning (spawn+p0wn).

Step 1:

Prepare an email that looks like:

Dear :

As a service to our customers and in an effort to protect their HSBC Premier  MasterCard  account, we are attempting to confirm recent charge activity or changes to the account.

Please contact the HSBC Premier Fraud Servicing Center to validate the activity at 1-888-206-5963 within the Continental United States. If you are calling from outside the United States, please call us collect at 716-841-7755.

If the activity is unauthorized, we will be able to close the account and reissue both a new account number and cards. Please use the Subject Reference Number below, when calling.

At HSBC, the security of our customer’s accounts has always been, and will continue to be a high priority. We appreciate your business and regret any inconvenience this may have caused you.

Sincerely,

Security & Fraud Risk HSBC USA

Alert ID Number :  10917558

Note:  Emails sent to this repository will go unmonitored.  Please do not reply to this email. —————————————– ************************************************************** This e-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ************************************************************** “SAVE PAPER – THINK BEFORE YOU PRINT!”

Step 2:

Replace the phone numbers with your own. The above are HSBC’s.

Don’t worry about the ‘alert ID’. Just make something up. Unlike other credit cards, the caller (me, in this case) can’t use the alert ID to confirm this is really HSBC.

Step 3:

Blast this email. You’re bound to reach plenty of HSBC card holders. The rest you don’t care about anyway.

Main perk: Before the customer gets to speak to a human they need to enter full credit card number and 4 digit SSN. So even the most lazy scammer can at least get those.

For the overachieving scammers, have a human answer and ask for  Card expiration and Full name on the card before agreeing to answer any other questions from the customer. This is all standard procedure at HSBC so customers shouldn’t be suspicious.

Oh, and if the customer who happens to be a security blogger tries to authenticate you back, tell them to hang up and call the number on the back of their card. That will shut them up.

At HSBC, the security of our customer’s accounts has always been, and will continue to be a high priority.

If it really was, you wouldn’t make me such an easy target for scammers. But thanks for playing.

NOPcon is a non-profit and free hacker conference which will be held in Istanbul, TURKEY on the 21 May.
The conference will be the first technical and international hacker conference in Istanbul. The conference aims to learn and exchange ideas and experiences between researchers , consultants and developers.

SPEAKERS
Moti Joseph – “Advanced Browser Exploiting”
Mohhammad Hluchan – “Militarization of Hacking and the New Cyber Arms Race in the Middle East”
Sertan Kolat – “Attacking iOS Applications”
Yasin Surer – “Kernel Exploiting”
Mert Sarica – “Attacking Android Applications”
Nebi Senol Yilmaz – “Defeating DDOS in FreeBSD Kernel”
Melih Tas – “Penetration Testing VOIP”
Ozan Ucar – “Real-world Penetration Testing Examples [Workshop]”
Evren Yalcin – “Advanced Web Application Security [Workshop]”
Celil Unuver – “SCADA (in)Security”

Registration
Registration for the conference can be made at free: http://www.nopcon.org/register/

Following the explosions in two BC sawmills, which experts are speculating may have been caused by fine sawdust caused by excessively dry wood, the TSA has banned any particulate materials, such as sawdust, flour, and icing sugar, to be banned from all flights.

Also included in the ban are any objects made from particulate materials, such as particleboard, bread, and icing sugar dusted donuts.  (The union representing TSA workers had argued, unsuccessfully, against this last item.)  The TSA’s Director Of Really Dangerous Stuff also noted that materials with larger particle sizes, such as table salt and sand, were also being included in the ban.

At press time, we were still awaiting word on whether computer equipment was to be included in the ban, since silicon chips are commonly said to be made of sand.

(Yeah, yeah, I know, don’t give the TSA ideas …)

BKDRKMKT.RVW 20120201

“Dark Market: CyberThieves, CyberCops, and You”, Misha Glenny, 2011,
978-0-88784-239-9, C$29.95
%A   Misha Glenny
%C   Suite 801, 110 Spadina Ave, Toronto, ON Canada  M5V 2K4
%D   2011
%G   978-0-88784-239-9 0-88784-239-9
%I   House of Anansi Press Ltd.
%O   C$29.95 416-363-4343 fax 416-363-1017 www.anansi.ca
%O  http://www.amazon.com/exec/obidos/ASIN/0887842399/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0887842399/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0887842399/robsladesin03-20
%O   Audience n Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   296 p.
%T   “Dark Market: CyberThieves, CyberCops, and You”

There is no particular purpose stated for this book, other than the vague promise of the subtitle that this has something to do with bad guys and good guys in cyberspace.  In the prologue, Glenny admits that his “attempts to assess when an interviewee was lying, embellishing or fantasising and when an interviewee was earnestly telling the truth were only partially successful.”  Bear in mind that all good little blackhats know that, if you really want to get in, the easiest thing to attack is the person.  Social engineering (which is simply a fancy way of saying “lying”) is always the most effective tactic.

It’s hard to have confidence in the author’s assessment of security on the Internet when he knows so little of the technology.  A VPN (Virtual Private Network) is said to be a system whereby a group of computers share a single address.  That’s not a VPN (which is a system of network management, and possibly encryption): it’s a description of NAT (Network Address Translation).  True, a VPN can, and fairly often does, use NAT in its operations, but the carelessness is concerning.

This may seem to be pedantic, but it leads to other errors.  For example, Glenny asserts that running a VPN is very difficult, but that encryption is easy, since encryption software is available on the Internet.  While it is true that the software is available, that availability is only part of the battle.  As I keep pointing out to my students, for effective protection with encryption you need to agree on what key to use, and doing that negotiation is a non-trivial task.  Yes, there is asymmetric encryption, but that requires a public key infrastructure (PKI) which is an enormously difficult proposition to get right.  Of the two, I’d rather run a VPN any day.

It is, therefore, not particularly surprising that the author finds that the best way to describe the capabilities of one group of carders was to compare them to the fictional “hacking” crew from “The Girl with the Dragon Tattoo.”  The activities in the novel are not impossible, but the ability to perform them on demand is highly
unlikely.

This lack of background colours his ability to ascertain what is possible or not (in the technical areas), and what is likely (out of what he has been told).  Sticking strictly with media reports and indictment documents, Glenny does a good job, and those parts of the book are interesting and enjoyable.  The author does let his taste for mystery get the better of him: even the straight reportage parts of the book are often confusing in terms of who did what, and who actually is what.

Like Dan Verton (cf BKHCKDRY.RVW) and Suelette Dreyfus (cf. BKNDRGND.RVW) before him, Glenny is trying to give us the “inside story” of the blackhat community.  He should have read Taylor’s “Hackers” (cf BKHAKERS.RVW) first, to get a better idea of the territory.  He does a somewhat better job than Dreyfus and Verton did, since he is wise enough to seek out law enforcement accounts (possibly after reading Stiennon’s “Surviving Cyberwar,” cf. BKSRCYWR.RVW).

Overall, this work is a fairly reasonable updating of Levy’s “Hackers” (cf. BKHACKRS.RVW) of almost three decades ago.  The rise of the financial motivation and the specialization of modern fraudulent blackhat activity are well presented.  There is something of a holdover in still portraying these crooks as evil genii, but, in the main, it is a decent picture of reality, although it provides nothing new.

copyright, Robert M. Slade   2012    BKDRKMKT.RVW 20120201

I made a posting on the blog.

Then I moved on to checking news, which I do via Twitter.  And, suddenly, there in my stream was a “tweet” that, fairly obviously, referred to my posting.  By someone I didn’t know, and had never heard of.  From Indonesia.

This blog now has an RSS feed.  Apparently a few people are following that feed.  And, seemingly, every time something gets posted here, it gets copied onto their blogs.

And, in at least one case, that post gets automatically (and programmatically) posted on Twitter.

I would never have known any of this, except that the posting I had made was in reference to something I had found via those stalwarts at the Annals of Improbable Research.  I had made reference to that fact in the first line.  The application used to generate the Twitter posting copies roughly the first hundred characters of the blog post, so the Improbable Research account (pretty much automatically) retweeted the programmed tweet of the blog posting that copied my original blog posting.  I follow Improbable Research on Twitter, so I got the retweet.

This set me to a little exploration.  I found, checking trackbacks, that every one of my postings was being copied to seven different blogs.  Blogs run by people of whom I’d never heard.  (Most of whom don’t seem to have any particular interest in infosec, which is rather odd.)

Well, this blog is public, and my postings are public, so I really can’t complain when the material goes public, even if in a rather larger way than I originally thought.  But it does underline the fact that, once posted on the Internet, it is very unsafe to assume that any information is confidential.  You can’t delete data once it has passed to machines beyond your control.

And it passes very, very fast.

BKSTVJBS.RVW 20111224

“Steve Jobs”, Walter Isaacson, 2011, 978-1-4104-4522-3
%A   Walter Isaacson pat.zindulka@aspeninstitute.org
%C   27500 Drake Road, Farmington Hills, MI   48331-3535
%D   2011
%G   978-1-4104-4522-3 1451648537
%I   Simon and Schuster/The Gale Group
%O   248-699-4253 800-877-4253 fax: 800-414-5043 galeord@gale.com
%O  http://www.amazon.com/exec/obidos/ASIN/1451648537/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1451648537/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1451648537/robsladesin03-20
%O   Audience n+ Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   853 p.
%T   “Steve Jobs”

I have read many fictional works that start off with a list of the cast of characters, but this is the first biography I’ve ever read that started in this way.

It is fairly obvious that Isaacson has done extensive research, talked to many people, and worked very hard in preparation for this book.  At the same time, it is clear that many areas have not been carefully analyzed.  Many Silicon Valley myths (such as the precise formulation of Moore’s Law, or John Draper’s status with regard to the Cap’n Crunch whistle) are retailed without ascertaining the true facts.  The information collected is extensive in many ways, but, in places (particularly in regard to Jobs’ earlier years) the writing is scattered and disjointed.  We have Jobs living with his girlfriend in a cabin in the hills, and then suddenly he is in college.

Material is duplicated and reiterated in many places.  Quotes are frequently repeated word-for-word in relation to different situations or circumstances, so the reader really cannot know the original reference.  There are also contradictions: we are told that Jobs could not stand a certain staffer, but 18 pages later we are informed that the same person often enthralled Jobs.  (Initially, this staffer is introduced as having been encountered in 1979, but it is later mentioned that he worked for Jobs and Apple as early as 1976.)  At one point we learn that an outside firm designed the Mac mouse: four pages further on we ascertain that it was created internally by Apple.  The author seems to have accepted any and all input, perspectives, and stories without analysis or assessment of where the truth might lie.

It is possible to do a biography along a timeline.  It is possible to do it on a thematic basis.  Isaacson follows a timeline, but generally only covers one subject during any “epoch.”  From the first time Jobs sees a personal computer until he is dismissed from Apple, this is less of a biography and more the story of the development of the company.  There is a short section covering the birth of Jobs’ daughter, we hear of the reality distortion field, and terse mentions of vegan diets, motorcycles, stark housing, and occasional girlfriends, but almost nothing of Jobs away from work.  (Even in covering Apple there are large gaps: the Lisa model is noted as an important development, but then is never really described.)

In fact, it is hard to see this book as a biography.  It reads more like a history of Apple, although with particular emphasis on Jobs.  There are sidetrips to his first girlfriend and daughter, NeXT, Pixar, miscellaneous girlfriends, his wife and kids, Pixar again, and then cancer, but by far the bulk of the book concentrates on Apple.

The “reality distortion field” is famous, and mentioned often.  Equally frequently we are told of a focused and unblinking stare, which Jobs learned from someone, and practiced as a means to intimidate and influence people.  Most people believe that the person who “doesn’t blink” is the dominant personality, and therefore the one in charge.  It is rather ironic that research actually refutes this.  Studies have shown that, when two people meet for the first time, it is actually the dominant personality that “blinks first” and looks away, almost as a signal that they are about to dominate the conversation or interaction.  Both “the field” and “the stare” seem to tell the same story: they are tricks of social engineering which can have a powerful influence, but which are based on an imperfect understanding of reality and people, don’t work with everyone, and can have very negative consequences.

(The chapters on Jobs’ fight with cancer are possibly the most telling.  For anyone who has the slightest background in medicine it will be apparent that Jobs didn’t know much in that field, and that he made very foolish and dangerous decisions, flying in the face of all advice and any understanding of nutrition and biology.)

Those seeking insight into the character that built a major corporation may be disappointed.  Like anybody else, Jobs is a study in contradictions: the seduction with charm and vision, then belittlement and screaming at people; the perfectionist who obsessed on details, but was supposedly a visionary at the intersection of the arts and technology who made major decisions based on intuitive gut feelings with little or no information or analysis; the amaterialistic ascetic who made a fortune selling consumer electronics and was willing to con people to make money; the Zen meditator who never seemed to achieve any calm or patience; the man who insisted that “honesty” compelled him to abuse friends and colleagues, but who was almost pathological in his secrecy about himself and the company; and the creative free-thinker who created the most closed and restricted systems extent.

There is no attempt to find the balance point for any of these dichotomies.  As a security architect I can readily agree with the need for high level design to drive all aspects of the construction of a system: a unified whole always works better and more reliably.  Unfortunately for that premise, there are endless examples of Jobs demanding, at very late points in the process, that radically new functions be included.  Then there is Jobs’ twin assertions that the item must be perfect, but that ship dates must be met.  One has to agree with Voltaire: the best is the enemy of the good, and anyone trying to be good, fast, *and* cheap may succeed a time or two, but is ultimately headed for failure.

Several times Isaacson repeats an assertion from Jobs that money is not important: it is merely recognition of achievements, or a resource that enables you to make great products.  The author does not seem to understand that an awful lot of money is also another resource, one that allows you to make mistakes.  He only vaguely admits that Jobs made some spectacular errors.

The book is not a hagiography.  Isaacson is at pains to point out that he notes Jobs’ weaknesses of character and action.  At the same time, Isaacson is obviously proud of being a personal friend, and, I suspect, does not realize that, while he may mention Jobs’ flaws, he also goes to great lengths to excuse them.

Was Steve Jobs a great man?  He was the driving force behind a company which had, for a time, the largest market capitalization of any publicly traded company.  He was also, by pretty much all accounts, an arrogant jerk.  He had a major influence on the design of personal electronics, although his contribution to personal computing was mostly derivative.  We are conventionally used to saying that people like Napoleon, Ford, and Edison are great, even thought they might have been better at social engineering than the softer people skills.  By this measure Jobs can be considered great, although not by the standards by which we might judge Ghandi, Mother Teresa, and the Dalai Lama (which is rather ironic, considering Jobs’ personal philosophy).

Those who hold Jobs, Apple, or both, in awe will probably be delighted to find a mass of stories and trivia all in one place.  Those who want to know the secrets of building a business empire may find some interesting philosophies, but will probably be disappointed: the book tends to take all positions at once.  For those who have paid much attention to Apple, and Jobs’ career, there isn’t much here that is novel.  As Jobs himself stated to a journalist, “So, you’ve uncovered the fact that I’m an *sshole.  Why is that news?”

Having all of the material in one book does help to clarify certain issues.  Personally, I have always fought with the Macs I used, struggling against the lock step conformity they enforced.  It was only in reviewing this work that it occurred to me that Apple relies upon a closed system that makes Microsoft appear open by comparison.  So, I guess, yes, there is at least one insight to be gained from this volume.

copyright, Robert M. Slade   2011     BKSTVJBS.RVW 20111224

I had a call today inviting me to “attend” a Webcast.  The vendor makes security products.  I work in security.  I won’t be attending.

I never watch Webcasts.  In the early days I watched a couple.  I even presented on a couple of Webcasts, at the request of different parties.  I’ve subsequently made it a policy that I never do attend.

Webcasts are a waste of time.

Back before Webcasts we had podcasts.  I could partially see a reason for podcasts.  After all, as the name implies, you were supposed to download them and play them on your iPod or other MP3 player.  You could do this on your commute, or while out jogging, or any other time that you would spend plugged into your device.  So, on what would normally be mental downtime, you could be learning something.

For me, personally, there were a couple of problems with this.  The first was that I never bothered to get an MP3 player.  The second was that I always had books to read (and review) on my commute.

Yes, I know I could download the podcasts to my computer, and listen to them that way.  But a) when I’m at the computer, that’s not downtime, and b) I can read faster than you can talk.  So listening to a podcast is still a waste of time.  Sorry to my friends who do podcasts, and I know you are sincerely trying to help (and probably do), but even if you are podcasting on an interesting topic, somebody else has written about it.  And I can search and read faster than you can talk.

The same goes, in spades, for Webcasts.  In addition, whereas podcasts are generally done by people who have something to say, but no money or major resources to say it with, Webcasts are done by vendors.  And trade rags (who are, these days, desperately trying to find something to make themselves relevant again).  And erstwhile conference and event promoters, who see it as a cheaper way to get the (advertising) message out.

And that’s part of the trouble.  It is cheaper.  A Webcast, no matter how many frills you add (sometimes turning it into a “virtual trade show” or “virtual conference”) is going to be cheaper than renting a hotel facility, flying actual people in, laying on coffee (at hotel catering prices), and advertising your event to get people to come.  If a vendor or promoter has to do all that, they figure they might as well make sure someone is going to listen to the pitch.  So they are much more likely to make sure that a) the speaker knows how to speak, b) the speaker has something to say, and c) there is some actual useful content in addition to the straight sales pitch.

But a Webcast is cheap.  No rooms to rent, no people to move, no coffee to buy.  Even if you have to rent Webcast time, it’s a pittance compared to all of that.

And, hey! you can get people to attend more easily!  From the comfort of their own desk or computer!  Wherever they are (as long as they can get to a hotspot)!  All they have to do is register and log in!

(I’ll come back to that.)

So, if a Webcast is cheap and easy, why take any trouble with it?  Drag in anyone as a speaker.  There are probably any number of people who think they could make it big on the lecture circuit if only they got a little “exposure.”  Sorry, but I’ve run into too many people who thought I should be glad to write or speak for them just for the “exposure.”  They only people who are going to fall for that are those who don’t get asked because a) they have nothing to say, and b) they can’t say it anyway.  Even if you do find someone with something to say, why give them time (and possibly money) to research or prepare anything?  As a matter of fact, if you are a trade rag you’ve probably got lots of people who are willing to be expert on anything, with a moment’s notice.

Like I said, I attended a few.  It very quickly became apparent not only that I can read faster than Webcasters can speak, but that almost none of them had anything worth saying anyway.

(I’ll make an exception for TED.  Not even all of TED.  But definitely Cliff Stoll.)

So, I made it a policy never to attend Webcasts.  We are all busy.  My time is finite.  Webcasts are a waste of time.

I said I’d come back to this business of it being easy to get people to come.  Recently I’ve noticed that the Webcasts aren’t just being advertised.  Now there are bribes and come-ons.  You can win an iPod, or an IPad, if you register and attend.  You can get a USB drive if you attend.  You can get a Starbucks card or an Amazon giftcard.  (I am somewhat reminded of the studies where they offered people chocolate bars or Starbucks cards if the people would tell their passwords.)  And not only am I getting multiple invites to the event, but now telemarketers are calling to “invite” me to attend.  They are starting to sound desperate.

Do you think it just vaguely possible that other people are starting  to think Webcasts are a waste of time?  Maybe a large number of other people?

Galina Pildush ended her LTE presentation with a very good question:”Who is responsible for LTE security?  Is it the users? UE (User Equipment, handsets and devices) manufacturers and vendors?  Network providers, operators and telcos?”

It’s a great question, and one that needs to be applied to every area of security.

In the SOHO (Small Office/Home Office) and personal sphere, it has long been assumed that it’s the user who is responsible.  Long assumed, but possibly changing.  Apple, particularly with the iOS/iPhone/iPad lines, has moved toward a model where the vendor (Apple) locks down the device, and only allows you certain options for software and services.  Not all of them are produced or provided by Apple, but Apple gets vetting responsibilities and rights.

The original “user” responsibility model has not worked particularly well.  Most people don’t know how to protect themselves in regard to information security.  Malware and botnets are rampant.  In the “each man for himself” situation, many users do not protect themselves, with significant consequences for the computing environment as a whole.  (For years I have been telling corporations that they should support free, public security awareness training.  Not as advertising or for goodwill, but as a matter of self defence.  Reducing the number of infected users out there will reduce the level of risk in computing and communication as a whole.)

The “vendor” model, in Apple’s case (and Microsoft seems to be trying to move in that direction) has generated a reputation, at least, for better security.  Certainly infection and botnet membership rates appear to be lower in Macs than in Windows machines, and lower still in the iOS world.  (This, of course, does nothing to protect the user from phishing and other forms of fraud.  In fact, it would be interesting to see if users in a “walled garden” world were slightly more susceptible to fraud, since they were protected from other threats and had less need to be paranoid.)  The model also has significant advantages as a business model, where you can lock in users (and providers, as well), so it is obviously going to be popular with the vendors.

Of course, there are drawbacks, for the vendors, in this model.  As has been amply demonstrated in current mobile network situations, providers are very late in rolling out security patches.  This is because of the perception that the entire responsibility rests with the provider, and they want to test every patch to death before releasing it.  If that role falls to the vendors, they too will have to take more care, probably much more care, to ensure software is secure.  And that will delay both patch cycles and version cycles.

Which, of course, brings us to the providers.  As noted, there is already a problem here with patch releases.  But, after all, most attacks these days are network based.  Proper filtering would not only deal with intrusions and malware, but also issues like spam and fraud.  After all, if the phishing message never reaches the user, the user can’t be defrauded.

So, in theory, we can make a good case that the provider would be the most effective locus for responsibility for security.  They have the ability to address the broadest range of security issues.  In reality, of course, it wouldn’t work.

In the first place, all kinds of users wouldn’t stand for it.  Absent a monopoly market, any provider who tried to provide total security protection, would a) incur prohibitively heavy costs (putting pressure on their competitive rates), and b) lose a bunch of users who would resent restrictions and limitations.  (At present, of course, me know that many providers can get away with being pretty cavalier about security.)  The providers would also, as now, have to deal with a large range of devices.  And, if responsibility is lifted from the vendors, the situation will only get worse: vendors will be able to role out new releases and take even less care with testing than they do now.

In practical terms, we probably can’t, and shouldn’t decide this question.  All parties should take some responsibility, and all parties should take more than they do currently.  That way, everybody will be better off.  But, as Bruce Schneier notes, there are always going to be those who try and shirk their responsibility, relying on the fact that others will not.

LTE.  Even the name is complex: Long-Term Evolution of Evolved Universal Terrestrial Radio Access Network

All LTE phones (UE, User Equipment) are running servers.  Multiple servers.  (And almost all are unsecured at the moment.)

Because of the proliferation of protocols (GSM, GPRS, CDMA, additional 3 and 4G, and now LTE), the overall complexity of the mobile/cell cloud is growing.

LTE itself is fairly complex.  The Protocol Reference Model contains at least the GERAN User Plane, UTRAN User Plane, and E-UTRAN User Plane (all with multiple components) as well as the control plane.  A simplified model of a connection request involves at least nine messages involving six entities, with two more sitting on the sides.  The transport layer, SCTP, has a four-way, rather than two-way, handshake.  (Hence the need for all those servers.)  Basically, though, LTE is IP, but a fairly complex set of additional protocols, as opposed to the old PSTN.  The old public telephone network was a walled garden which few understood.  Just about all the active blackhats today understand IP, and it’s open.  It’s protected by Diameter, but even the Diameter implementation was loopholes.  It has a tunnelling protocol, GTP (GPRS Tunnelling Protocol), but, like very many tunnelling protocols, GTP does not provide confidentiality or integrity protection.

Everybody wants to the extra speed, functions, interconnection abilities, and apps.  But all the functionality means a much larger attack surface.  The total infrastructure involved in LTE is more complex.  Maybe nobody can know it all.  But they can know enough to start messing with it.  From a simple DoS to DDoS, false billing, disclosure of data, malware, botnets of the UEs, spam, SMS trojans, even run down batteries, you name it.

As with VoIP before it, we are rolling our known data vulnerabilities, and known voice/telco/PBX vulnerabilities, into one big insecurity.

Let me say, right off the top, that I love CanSecWest.  I am tired of “vendor” conferences, where you pay outrageous fees for the privilege of sitting through a bunch of sales pitches.  At least CanSecWest has real information, as opposed to virtual information.  (Virtual information: n. – marketing spiel dressed up as actual technical information.)

However, today I have had the same conversation half a dozen times, with half a dozen different people.  (And I didn’t initiate any of them.)  The conversation generally starts out the same way, with the question, “Don’t you think CanSecWest is getting … less technical?”

Now, it may simply be a one year glitch, or a random set of presentations.  But, yes, I have to agree that, so far, the presentations have not been as great as in the past.

Still good, don’t get me wrong.  But we started with a pres on the boot process, nicely technical, but nothing new.  Pen testing, which was also pretty generic, and nothing new.  The social authentication, yes, that was good.  Recent research, and some neat ideas to play with.  The piece on APT was mostly about finding bugs in Shockwave/Flash.  The piece on Duqu and Stuxnet was good, but I feel a bit used: Kaspersky obviously timed it to present the same thing at both CanSecWest and CeBit at the same time.  Good PR hack, but a bit of a cheat in terms of “unique” presentations that haven’t been done before.

The smartphone rooting had some interesting points, but didn’t demonstrate real exploits.  The probing of mobile networks had more real and technical data.  (Marcia Hoffman’s presentation was, last year, a personal disappointment to me, since I’m a legal and forensics guy, and expected more depth.  However, when I thought about it, I realized that she had nailed the target audience: these guys are geeks, and need the basic warnings about what they are doing.  She did just as well this year.)

The iOS exploitation pres was interesting but covered material that was covered quite well last year.  The piece on hardware-involved attacks boiled down to “if you don’t take care with your programming, hardware can do things you don’t expect: be a careful programmer.”  The Near Field Communications (NFC) item did raise some interesting points about the careless acceptance of chip codes, but most of it was little different from discussions about RFID or validating input in general.  (The HDMI was pretty cool.)

Like I said, I love CanSecWest, and I’m still going to come.  I may complain a bit about these presentations, but they are still far above anything you are likely to find at a vendor conference.  But I hope the program gets back to some solid, new technical stuff.

(By the way, if you want more details about the specific presentations, the slides are generally made available in an archive shortly after the event closes.  It’ll probably be this link, or something similar.)

Mobile networks have many disparate types of devices.  You can probably guess what some of them are, or even go to the provider’s store or kiosk and get a list.  But there are going to be more devices out there.  So why not scan the IP addresses on your subnet?

Well, the access points for mobile networks generally don’t allow promiscuous access.  So you may have to go to ARIN and other lists in order to start getting some ranges to check.  You can also check access logs of a Website to find visitors with mobile devices.  (Of course, there is always the NATting that the providers do, not to mention DHCP, and the fact that most mobile devices don’t run servers or services.)

Colin Mulliner, of the Berlin Institute of Technology, did manage to find a fair amount of interesting stuff.  Windows Mobile tended to be a useful source of open ports and services (usually open FTP services on mobile devices).  He also found and was able to identify a number of specialized devices that were identifiable from responses to probes.  Some of the most interesting were mobile access points: connecting to the mobile networks and then providing local wifi for computers.  Others were HTTP servers for surveillance cameras.  (Others were GPS tracking devices which, oddly, had no security against “guest” login  :-)  (Some were smart meters.  With smart meters rolling out here in BC, lets hope they are more secure …)

Possibly of concern was the large number of jailbroken iOS devices.  Many of them still had the default “alpine” password.  (If you hack your own device, you’d better be prepared to secure it.)  This could form the basis of a fair sized worm and/or botnet.  Then again, iOS users aren’t alone here.  An awful lot of people seem to think nothing of creating mobile devices and hooking them up to mobile networks with very little in the way of security.

Scott Kelly, platform architect at Netflix, gets to look at a lot of devices.  In depth.  He’s got some interesting things to say about smartphones.  (At CanSecWest.)

First of all, with a computer, you are the “tenant.”  You own the machine, and you can modify it any way you want.

On a smartphone, you are not the only tenant, and, in fact, you are the second tenant.  The provider is the first.  And where you may want to modify and customize it, the provider may not want you to.  They’d like to lock you in.  At the very least, they want to maintain some control because you are constantly on their network.

Now, you can root or jailbreak your phone.  Basically, that means hacking your phone.  Whether you do that or not, it does mean that your device is hackable.

(Incidentally, the system architectures for smartphones can be hugely complex.)

Sometimes you can simply replace the firmware.  Providers try to avoid doing that, sometimes looking at a secure boot system.  This is usually the same as the “trusted computing” (digital signatures that verify back to a key that is embedded in the hardware) or “trusted execution” (operation restriction) systems.  (Both types were used way back in AV days of old.)  Sometimes the providers ask manufacturers to lock the bootloader.  Attackers can get around this, sometimes letting a check succeed and then doing a swap, or attacking write protection, or messing with the verification process as it is occurring.  However, you can usually find easier implementation errors.  Sometimes providers/vendors use symmetric enryption: once a key is known, every device of that model is accessible.  You can also look at the attack surface, and with the complex architectures in smartphones the surface is enormous.

Vendors and providers are working towards trusted modules and trustzones in mobile devices.  Sometimes this is virtual, sometimes it actually involves hardware.  (Personally, I saw attempts at this in the history of malware.  Hardware tended to have inherent advantages, but every system I saw had some vulnerability somewhere.)

Patching has been a problem with mobile devices.  Again, the providers are going to be seen as responsible for ongoing operation.  Any problems are going to be seen as their fault.  Therefore, they really have to be sure that any patch they create is absolutely bulletproof.  It can’t create any problems.  So there is always going to be a long window for any exploit that is found.  And there are going to be vulnerabilities to exploit in a system this complex.  Providers and vendors are going to keep trying to lock systems.

(Again, personally, I suspect that hacks will keep on occurring, and that the locking systems will turn out to be less secure than the designers think.)

Scott is definitely a good speaker, and his slides and flow are decent.  However, most of the material he has presented is fairly generic.  CanSecWest audiences have come to expect revelations of real attacks.