Rootkits

BadBIOS

In recent days there has been much interest in the “BadBIOS” infection being reported by Dragos Ruiu.  (The best overview I’ve seen has been from Naked Security.)  But to someone who has lived through several viral myths and legends, parts of it sound strange.

  • It is said to infect the low-level system firmware of your computer, so it can’t be removed or disabled simply by rebooting.

These things, of course, have been around for a while, so that isn’t necessarily wrong.  However, BIOS infectors never became a major vector.

  • It is said to include components that work at the operating system level, so it affects the high-level operation of your computer, too.
  • It is said to be multi-platform, affecting at least Windows, OS X, and OpenBSD systems.

This sounds bit odd, but we’ve had cross-platform stuff before.  But they never became major problems either.

  • It is said to prevent infected systems being booted from CD drives.

Possible: we’ve seen similar effects over the years, both intentionally and un.

  • It is said to spread itself to new victim computers using Software Defined Radio (SDR) program code, even with all wireless hardware removed.

OK, it’s dangerous to go out on a limb when you haven’t seen details and say something can’t happen, but I’m calling bullshit on this one.  Not that I don’t think someone couldn’t create a communications channel without the hardware: anything the hardware guys can do the software guys can emulate, and vice versa.  However, I can’t see getting an infection channel this way, at least without some kind of minimal infection first.  (It is, of course, possible that the person doing the analysis may have made a mistake in what they observed, or in the reporting of it.)

  • It is said to spread itself to new victim computers using the speakers on an infected device to talk to the microphone on an uninfected one.

As above.

  • It is said to infect simply by plugging in a USB key, with no other action required.

We’ve seen that before.

  • It is said to infect the firmware on USB sticks.

Well, a friend has built a device to blow off dangerous firmware on USB sticks, so I don’t see that this would present any problem.

  • It is said to render USB sticks unusable if they aren’t ejected cleanly; these sticks work properly again if inserted into an infected computer.

Reminds me somewhat of the old “fast infectors” of the early 90s.  They had unintended effects that actually made the infections easy to remove.

  • It is said to use TTF (font) files, apparently in large numbers, as a vector when spreading.

Don’t know details of the internals of TTF files, but they should certainly have enough space.

  • It is said to block access to Russian websites that deal with reflashing software.

Possible, and irrelevant unless we find out what is actually true.

  • It is said to render any hardware used in researching the threat useless for further testing.

Well, anything that gets reflashed is likely to become unreliable and untrustworthy …

  • It is said to have first been seen more than three years ago on a Macbook.

And it’s taken three years to get these details?  Or get a sample to competent researchers?  Or ask for help?  This I find most unbelievable.

In sum, then, I think this might be possible, but I strongly suspect that it is either a promotion for PacSec, or a promo for some presentation on social engineering.

 

Smartphone vulnerabilities

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.

“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 www.zerodaythebook.com markrussinovich@hotmail.com
%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   josephrinaldi@stmartins.com christopherahearn@stmartins.com
%O  http://www.amazon.com/exec/obidos/ASIN/031261246X/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/031261246X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/031261246X/robsladesin03-20
http://www.amazon.com/gp/mpd/permalink/m3CQBX46DOK0AK/ref=ent_fb_link
%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

Shaw and Spamhaus

I seem to be back on the air.

A few observations over this whole affair:

(Sorry, I’ve not had time to put these in particular order, and some of the point may duplicate or relate …)

1) I still have absolutely no idea why Shaw cut me off.  They keep blaming Spamhaus, but the only links they offer me as evidence clearly show that there is no “bad reputation” in the specific IP address that I am currently using, only a policy listing showing one of Shaw’s address ranges.

2) I got absolutely no warning from Shaw, and no notice after the fact.

3) Shaw’s spam filtering is for the birds.  Today I got two messages flagged as spam, for no clear reason I could see.  They were from a publisher, asking how to send me a book for review.  The only possible reason I could see was that the publisher copied three of my email addresses on the same message.  A lot of people do that, but it usually doesn’t trip the spam filter.  Today it did.  (Someone else with Shaw “service” tried to send out an announcement to a group.  Since he didn’t have a mailing list server, he just sent out a bunch of messages.  Apparently that got *his* account flagged as spamming.)  I also got the usually round of messages from security mailing lists tagged as spam: Shaw sure has something against security.  And at least one 419 scam got through unflagged today, despite being like just about every other 419 in the world.  (Oddly, during this period I’ve noted a slight uptick in 419s and phishing in general.)

4) Through this episode I had contact with Shaw via email, phone, “live chat,” and Twitter.  I follow ShawInfo and Shawhelp on Twitter.  On Twitter, I was told to send them a direct message (DM).  I had, in fact, tried to do that, but Shaw doesn’t accept direct messages by default.  (Since I pointed that out to them, they now, apparently accept them from me.)  They sent me public messages on Twitter, and I replied in kind.  Through the Twitter account they also informed me that error 554 is “poor reputation” and is caused by sending too many emails.  They didn’t say how many is too many.  (Testing by someone else indicated something on the order of 50-100 per hour, and I’ve never done anything near that scale.)

5) The “live chat” function installs some software on your (the client) machine.  At least two of the pieces of software failed the digital signature verification …

6) The “information” I got from Shaw was limited.  The first (phone) support call directed me to http://www.senderbase.org/senderbase_queries/detailip?search_string=70.79.166.169  If you read the page, the information is almost entirely about the “network” with only a few (and not informative) pieces about the IP address itself.  (I did, separately, confirm that this was my IP address.)  The bulk of the page is a report on addresses that aren’t even in the same range as I am.  About halfway down the right hand side of the page is “DNS-based blocklists.”  If you click the “[Show/Hide all]” link you’ll notice that four out of five think I’m OK.  If you click on the remaining one, you go to http://www.spamhaus.org/query/bl?ip=70.79.166.169  At the moment, it shows that I’m completely OK.  At the time I was dealing with Shaw, it showed that it’s not in the SpamHaus Block List (SBL) or the XBL.  It was in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

7) The second (live chat) support call sent me to http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+  Again, this page showed a single negative entry, and a whole page of positive reports.  The single negative entry, if pursued, went to the same Spamhaus report as detailed above.

8) At the time, both initial pages, if followed through in terms of details, led to http://www.spamhaus.org/pbl/query/PBL164253 giving, as the reason, that “This IP range has been identified by Spamhaus as not meeting our policy for IPs permitted to deliver unauthenticated ‘direct-to-mx’ email to PBL users.”  Again, Shaw’s problem, not mine.  However, that page has a link to allow you to try and have an address removed.  However, it says that the “Removal Procedure” is only to be used “If you are not using normal email software but instead are running a mail server and you are the owner of a Static IP address in the range 70.79.164.0/22 and you have a legitimate reason for operating a mail server on this IP, you can automatically remove (suppress) your static IP address from the PBL database.”  Nevertheless, I did explore the link on that page, which led to http://www.spamhaus.org/pbl/removal/  Again, there you are told “You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server, and (B) if you have a specific technical reason for needing to run a ‘direct-to-MX’ email service, such as a mail server appliance, off the Static IP address. In all other cases you should NOT remove an IP address from the PBL.”  This did not refer to my situation.  Unfortunately, THESE TWO PAGES ARE INCORRECT.  If you do proceed beyond that page, you get to http://www.spamhaus.org/pbl/removal/form  This page does allow you to submit a removal request for a dynamic IP address, and, in fact, defaults to dynamic in the form.  It was only on the last part of the second call, when the Shaw tech gave me this specific address, that I found this out.  For this I really have to blame Spamhaus.

9) In trying to determine if, by some weird mischance, my computer had become infected, I used two AV scanners, one spyware scanner, and two rootkit scanners.  (All results negative, although the Sophos rootkit scanner could have been a bit clearer about what it had “found.”)  Of course, I’ve been in the field for over two decades.  How would the average user (or even a security professional in a non-malware field) even know that there are different types of scanners?  (Let alone the non-signature based tools.)