The “Man in the Browser” attack

Gizmodo reports:

New “Man in the Browser” Attack Bypasses Banks’ Two-Factor Authentication Systems

Except there is nothing new about this attack. OWASP documented it in 2007 and it was widely known that malware writers used it to bypass 2-factor authentication.

More from Gizmodo:

Since this attack has shown that the two-factor system is no longer a viable defense, the banking industry may have to adopt more advanced fraud-detection methods

Given that this has been going on for more than 5 years, it’s obvious that banks already have adopted more advanced fraud detection methods.

So why are they forcing you to carry around tokens and one-time passwords that make it awkward and uncomfortable to use your own money as you wish?

Because with only few exceptions, banks’ security guys are not interested in making your life comfortable. The more you suffer, the more you think they are secure.

Maybe it’s time to ask for accountability? Which of their so-called security features is really for security, and which is for CYA or ‘make-the-regulator-happy’?

“Zero Day”, Mark Russinovich

BKZERDAY.RVW   20111109

“Zero Day”, Mark Russinovich, 2011, 978-0-312-61246-7, U$24.99/C$28.99
%A Mark Russinovich
%C   175 Fifth Ave., New York, NY   10010
%D   2011
%G   978-0-312-61246-7 0-312-61246-X
%I   St. Martin’s Press/Thomas Dunne Books
%O   U$24.99/C$28.99 212-674-5151 fax 800-288-2131
%O   Audience n Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   328 p.
%T   “Zero Day”

Mark Russinovich has definitely made his name, in technical terms, with Winternals and Sysinternals.  There is no question that he knows the insides of computers.

What is less certain is whether he knows how to write about it within the strictures of a work of fiction.  The descriptions of digital forensics and computer operation in this work are just as confusing, to the technically knowledgeable, as those we regularly deride from technopeasant authors.  “[T]he first thing Jeff noted was that he couldn’t detect any data on the hard disk.”  (Emphasis in the book.)  Jeff then goes on to find some, and notes that there are “bits and pieces of the original operating system.”  Now there is a considerable difference between not finding any data, and having a damaged filesystem, and Russinovich knows this perfectly well.  Our man Jeff is a digital forensics hacker of the first water, and wouldn’t give a fig if he couldn’t see “the standard C: drive icon.”

Generally, you would think that the reason a technically competent person would write a novel about cyberwar would be in order to inject a little reality into things.  Well, reality seems to be in short supply in this book.

First of all, this is the classic geek daydream of being the ultimate ‘leet hacker in the world.  The Lone Hacker.  Hiyo SysInfo, away!  He has all the tools, and all that smarts, about all aspects of technology.  Sorry, just not possible any more.  This lone hacker image is unrealistic, and the more so because it is not necessary.  There are established groups in the malware community (among others), and these would be working together on a problem of this magnitude.  (Interestingly, these are generally informal groups, not the government/industry structures which the book both derides and relies upon.)

Next, all the female geeks (and there are a lot) are “hot.”  ‘Nuff said.

The “big, bad, new” virus is another staple of the fictional realms which does not exist in reality.  Viruses can be built to reproduce rapidly.  In that case, they get noticed quickly.  Or, they may be created to spread slowly and carefully, in which case they can take a while to be detected, but they also take a long time to get into place.

Anti-malware companies don’t necessarily rely on honeypots (which are usually there to collect information on actual intruders), but they do have bait machines that sit and wait to be infected (by worms) or emulate the activity of users who are willing to click on any link or open any file (for viruses).  Malware can be designed to fail to operate (or even delete itself) under certain conditions, and those conditions could include certain indications of a test environment.  However, the ability to actively avoid machines that might be collecting malware samples would be akin to a form of digital mental telepathy.

Rootkits, as described in the novel, are no different than the stealth technology that viruses have been using for decades.  There are always ways of detecting stealth, and rootkits, and, generally speaking, as soon as you suspect that one might be in operation you start to have ideas about how to find it.

A backup is a copy of data.  When it is restored, it is copied back onto the computer, but there is no need for the backup copy to be destroyed by that process.  Therefore, if a system-restored-from-backup crashes, nothing is lost but time.  You still have the backup, and can try again (this time with more care).  In fact, the first time you have any indication that the system might be corrupted enough to crash, you would probably try to recover the files with an alternate operating system.  (But, yes, I can see how that might not occur to someone who works for Microsoft.)  After all, the most important thing you’ve got on your system is the data, and the data can usually be read on any system, and with a wide variety of programs.  (Data files from a SQL Server database could be retrieved not only with other SQL programs, but with pretty much any relational database.)

Some aspects are realistic.  The precautions taken in communications, with throwaway email addresses and out-of-band messaging, are the type that would be used in those situations.  There is a lot of real technology described in the book.  (Although I was slightly bemused by the preference for CDs for data and file storage: that seems a bit quaint now that everyone is using USB drives.)  The need, in this type of work, for a level of focus that precludes all other distractions, and the boredom of trying step after step and possibility after possibility are real.  The neglect of security and the attendant false confidence that one is immune to attack are all too real.  But in a number of the technical areas the descriptions are careless enough to be completely misleading to those not intimately familiar with the technology and the information security field.  Which is just as bad as not knowing what you are talking about in the first place.

Other forms of technology should have had a little research.  Yes, flying an airliner across an ocean is boring.  That’s why the software designers behind the interface on said airliners have the computer keep asking the pilots to check things: keeps the pilots from zoning out.  I don’t know how quickly you can “reboot” the full control system in an airplane, but the last one I was on that did it took about fifteen minutes to even get the lights back on.  I doubt that would be fast enough to do (twice) in order to pull a plane out of a dive.  And if you are in a high-G curve to try and keep the plane out of the water, a sudden cessation of G-forces would mean that a) the plane had stalled (again) (very unlikely), or b) the wings had come off.  Neither of which would be a good thing.  (And, yes, the Spanair computer that was tracking technical problems at the time was infected with a virus, but, no, that had nothing to do with the crash.)

Russinovich’s writing is much the same as that of many mid-level thriller writers.  His plotting is OK, although the attempt to heighten tension, towards the end, by having “one darn thing after another” happen is a style that is overused, and isn’t very compelling in this instance.  On the down side, his characters are all pretty much the same, and through much of the book the narrative flow is extremely disjointed.

Overall, this is a reasonable, though unexceptional, thriller.  He was fortunate in being able to get Bill Gates and Howard Schmidt to write blurbs for it, but that still doesn’t make it any more realistic than the mass of cyberthrillers now coming on the market.

copyright, Robert M. Slade   2011     BKZERDAY.RVW   20111109

PC Support Sites: Scams and Credibility

Just as 419-ers seem to have been permanently renamed in some quarters as “the Lads from Lagos”, I wonder if we should refer to those irritating individuals who persist in ringing us to offer us help (for a not particularly small fee) with non-existent malware as the “Krooks from Kolkata” (or more recently, the Ne’erdowells from New Delhi). It would be a pity to slur an entire nation with the misdeeds of a few individuals, but the network of such scammers does seem to be expanding across the Indian continent.

Be that as it may, I’ve recently been doing a little work (in association with Martijn Grooten of Virus Bulletin) on some of the ways that PC support sites that may be associated with cold-call scams are bolstering their own credibility by questionable means. Of course, legitimate businesses are also fond of Facebook likes, testimonials and so on, but we’ve found that some of these sites are not playing altogether nicely.

I’ve posted a fairly lengthy joint blog on the topic here: Facebook Likes and cold-call scams

ESET Senior Research Fellow

History of crimeware?

C’mon, Infoworld, give us a break.

“There are few viable options to combat crimeware’s success in undermining today’s technologies.”

How about “don’t do dangerous stuff”?

“Crimeware: Foundation of today’s telescreens”

I’m sorry, what has “1984” to do with the use of malware by criminal elements?

“Advancement #1: Form-grabbing for PCs running IE/Windows
Form grabbing, as its name implies, is the crimeware technique for capturing web form data within browsers.”

Can you say “login trojan”?  I knew you could.  They existed even before PCs did.

“Advancement #2: Anti-detection (also termed stealth)”

Oh, no!  Stealth!  Run!  We’re all gonna die!

Possibly the first piece of malware to use some form of stealth technology to hide itself from detection was a virus.  Perhaps you might have heard of it.  It was called BRAIN, and was written in 1986.

“Advancement #5: Source code availability/release
The source codes for Zeus and SpyEye, among the most sophisticated crimeware, were publicly released in 2010 and 2011, respectively.”

And the source code for Concept, which was, at the time, the most sophisticated macro virus (since it was the only macro virus), was released in 1995, respectively.  But wait!  The source code for the CHRISTMA exec was released in 1988!  Now how terrified are you!

“Crimeware in 2010 deployed the capability to disable anti-malware products”

And malware in 1991 deployed the capability to disable CPAV and MSAV.  With only fourteen bytes of code.  As a matter of fact, that fourteen byte string came to be used as an antivirus signature for a while, since so many viruses were included it.

“Advancement #7: Mobile device support (also termed man-in-the-mobile)”

We’ve got “man in the middle” and “meet in the middle.”  Nobody is using “man in the mobile” except you.

“Advancement #8: Anti-removal (also termed persistence)
As security solutions struggle to detect and remove crimeware from compromised PCs, malware authors are updating their code to permit it to re-emerge on PCs even after its supposed removal.”

I’ve got four words for you: “Robin Hood” and Friar Tuck.”

The author “has served with the National Security Agency, the North Atlantic Treaty Organization, the U.S. Air Force, and two Federal think tanks.”

With friends like this, who needs enemies?

Nightmare on Malware Street

The Scientific American, no less, has published an article on malware.  Not that they don’t have every right, it’s just that the article is short on fact or help, and long on rather wild conjecture.

The author does have some points to make, even if he makes them very, very badly.

We, both as security professionals and as a society, don’t take malware seriously enough.  The security literature on the subject is appalling.  It is hard to find books on malware, even harder to find good ones, and well nigh impossible to find decent information in general security books.  The problem has been steadily growing since it was a vague academic topic, and has been ignored for so long that, now that it is a real problem, even most security experts have only a tenuous grasp of it.

Almost all reports do sound like paranoid thrillers.  Promoting the idea of shadowy genius figures in dark corners manipulating us at will, this engenders a kind of overall depression: we can’t possibly fight it, so we might was well not even try.  This attitude is further exacerbated but the dearth of information: we can’t even know what’s going on, so how can we even try to fight it?

It is getting more and more difficult to find malware, mostly because we are constantly creating new places for it to hide.  In the name of “user friendliness,” we are building ever more complex systems, with ever more crevices for the pumas to hide in.

Yes, then he goes off into wild speculation and gets all “Reflections on Trusting Trust” on us.  Which kind of loses the valid points.

The “Immutable Laws” revisited

Once upon a time, somebody at Microsoft wrote an article on the “10 Immutable Laws of Security.”  (I can’t recall how long ago: it’s now listed as “Archived content.”  And I like the disclaimer that “No warranty is made as to technical accuracy.”)  Now these “laws” are all true, and they are helpful reminders.  But I’m not sure they deserve the iconic status they have achieved.

In terms of significance to security, you have to remember that security depends on situation.  As it is frequently put, one (security) size does not fit all.  Therefore, these laws (which lean heavily towards malware) may not be the most important for all users (or companies).

In terms of coverage, there is little or nothing about management, risk management, classification, continuity, secure development, architecture, telecom and networking, personnel, incidents, or a whole host of other topics.

As a quick recap, the laws are:

Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore

(Avoid malware.)

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore

(Avoid malware, same as #1.)

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

(Quite true, and often ignored.  As I tell my students, I don’t care what technical protections you put on your systems, if I have physical access, I’ve got you.)

Law #4: If you allow a bad guy to upload programs to your website, it’s not your website any more

(Sort of a mix of access control and avoiding malware, same as #1.)

Law #5: Weak passwords trump strong security

(You’d think this relates to access control, like #4, but the more important point is that you need to view security holistically.  Security is like a bridge, not a road.  A road halfway is still partly useful.  A bridge half-built is a joke.  In security, any shortcoming can void the whole system.)

Law #6: A computer is only as secure as the administrator is trustworthy

(OK, there’s a little bit about people.  But it’s not just administrators.  Security is a people problem: never forget that.)

Law #7: Encrypted data is only as secure as the decryption key

(This is known as “Kerckhoffs’ Law.”  It’s been known for 130 years.  More significantly, it is a special case of the fact that security-by-obscurity [SBO] does not work.)

Law #8: An out of date virus scanner is only marginally better than no virus scanner at all

(I’m not sure that I’d even go along with “marginally.”  As a malware expert, I frequently run without a virus scanner: a lot of scanners [including MSE] impede my work.  But, if I were worried, I’d never rely on an out-of-date scanner, or one that I considered questionable in terms of accuracy [and there are lots of those around].)

Law #9: Absolute anonymity isn’t practical, in real life or on the Web

(True.  But risk management is a little more complex than that.)

Law #10: Technology is not a panacea

(Or, as (ISC)2 says, security transcends technology.  And, as #5 implies, management is the basic foundation of security, not any specific technology.)

Conflicting AVs

Well behaved anitvirus programs can safely work together in peace and harmony.

Unfortunately, relatively few AVs are well behaved.

On my new desktop, I’ve got Avast (came with the machine, has a free version, and is a pretty good product) and MSE (it’s free, and it’s pretty safe for most users, although, as a professional, some parts of it irk me).  I’ve set both to ignore the virus zoo, although they aren’t too good at taking that restriction to heart.

MSE quarantined a few samples before I got things tuned.  Of course, it doesn’t have any function to get stuff out of “quarantine.”  (As I say, as a professional this is irksome, but, considering the average user, I’d say this is a darn good thing.)

Today Avast gave me a warning of some dangerous files.  They were the ones MSE quarantined.

(In case anyone is interested, the quarantine seems to be in \ProgramData\Microsoft\Microsoft Antimalware\LocalCopy.)