New computers – Mac (nets)

One of my Mac fanatic contacts, when I mentioned that I needed to connect to my old Windows machines, said that it was easy, you just had to open “Networks,” and there they all are!  Well, no, not quite.  Not by a long shot, in fact.  I knew there was something called “Finder,” which was basically the interface to the filesystem on the Mac OS.  I even figured where to find it, going to the icon on the extreme left end of the top of the screen, and figuring that choosing the “Finder” under that option would change the top menu items from the browser that was active at the time.

So, I found Finder, and I even found the Network part of it.  And I asked it to search for servers.  It didn’t find any.  So I asked it to find a specific server.  It didn’t find that, either, but the fact that the name I had specified popped up with “afp:” at the beginning gave me an indication that I had to specify a protocol for Windows machines.  I went searching in the help files, and, eventually, found it.  Not too hard to figure out that it was “smb:”  at least, not too hard once you know it.  I then was able to figure out, on my own, that specifying the machine name with a leading “//” was wrong, because the Mac helpfully and intelligently adds “//” to whatever you type, but is too stupid to figure out that “////” is wrong.

New computers – Mac (basics)

My father-in-law is a dedicated Apple fanatic (as are a number of my friends).  Since I had an MS-DOS machine when we first met, he tagged me as an IBM person.  (It was vain to point out that, although I had once installed a Baby 36 for a charity, I did not, in fact, have a System 360 installed in the non-existent basement of my apartment.)  He eventually figured out that Microsoft made the operating system, but, even though I have worked on (among others) a predecessor to AOS(VS), Apple DOS, UNIX, TOPS-10, VMS, JCL, and CP/M, and make no secret of my frustrations with Windows, he still considers me to be one of “the enemy.”

Well, I’ve always wanted to have a crack at Macs.  I got the first one installed in one company I worked for, over twenty years ago, used it for a while, and, despite the frustrations, was still interested in getting one of my own.  So, this year, while I had the need to update at least two machines, and since the price had come down from “completely-out-of-the-question” to merely “obscene,” I decided to get one.

The experience has been interesting.  I shall, no doubt, have more to say about aspects of operation in the future, but it has been an education to get a new Mac (a MacBook Pro laptop) and take it out of the box.

To give credit where credit is due, I’ve got to say that I’ve been impressed with the performance of the Mac and the Safari browser on the Web, which is what I’ve done with it so far.  The overall design is nice, of course.  I like the battery life (so far), and the “sleep” mode performance.  The machine recognized a generic mouse I plugged into it, and happily connected to the Internet when through a wired LAN.  The minimal (well, OK, slightly more than minimal) experience I’ve had with Mac OS X was quite sufficient to get me started on the machine, and I’ve even managed to puzzle out some things with the help of the “Help” system (but more on that later).

The big thing with Mac advertising, and Mac devotees, is that the Mac is easy to use “right out of the box.”  And, yes, that is partially, and possibly even mostly, true.  But not completely.

The reason that I needed to plug in a mouse was that I could not figure out how to “choose” or activate something with the trackpad.  I could move the pointer around, no problem, but then there were no buttons to push.  Tapping didn’t work.  I remembered seeing people tapping hard on the trackpad on Mac laptops, so I tried that.  Sometimes it worked, and sometimes it didn’t.

Experienced Mac laptop users will be smirking, of course, knowing what I eventually found out.  You don’t tap the trackpad, or even tap it hard.  You press, deliberately, and you can actually feel a detent “click” when you’ve pressed hard enough.  (And, of course, whatever you wanted to activate gets activated.)  This is sort of implied in the documentation (when I found it), but even there isn’t really made clear.  And it certainly isn’t “intuitively obvious.”

Ah, yes, the documentation.  Once you’ve figured out how to open up the box the laptop comes in, you take the laptop out of the clear cellophane “envelope,” and open it up.  Since it is shipped with the battery charged, as soon as you take the protective foam sheet off the keyboard, and figure out the power button (not *too* hard, if you’ve got good eyes: white on silver is pretty, but not exactly clear) things start happening.  Once you’ve gotten over the excitement, you may notice that there are power cords in a bay at the back of the box.  You are less likely to notice that there is a black cardboard envelope nestled into the black packing material at the front of the box.  Pulling on a tab in just the right way starts to loosen this, although you still seem to have to find a finger hole in the envelope in order to get it out, and then figure out how to open it.  Once you do, you will find a brief booklet which does tell you which of the two power cords is actually a power cord, and which is a mere (and very short) extension cord.  It also tells you a few other things that would have been handy, had I not already figured them out by trial and (mostly) error.  (There is also a CD or DVD which I haven’t yet had the time to try out.)

OK, some of the design is great.  (Not insanely, but great.)  Not all of it.

FBI Planted backdoors in OpenBSD IPSEC?

Not sure what to make of this yet:

“FBI Added Secret Backdoors to OpenBSD IPSEC”

Theo De Raadt seems to be ambiguous about this:

It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack.  Around 2000-2001.


I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this.

Who’s behind Stuxnet?

Stuxnet is a worm that focuses on attacking SCADA devices. This is interesting on several levels.

First, we get to see all of those so-called isolated networks get infected, and wonder how that happened (here’s a clue: in 2010, isolated means in a concrete box buried underground with no person having access to it).

Then, we get to see how weak SCADA devices really are. No surprise to anyone who has ever fuzzed one.

After that, we get to theorize on who’s behind it and who is the target. What’s your guess?

Reflections on Trusting Trust goes hardware

A recent Scientific American article does point out that is is getting increasingly difficult to keep our Trusted Computing Base sufficiently small.

For further information on this scenario, see:  [1]

We actually discussed this in the early days of virus research, and sporadically since.  The random aspect (see Dell problems with bad chips) (the stories about malware on the boards is overblown, since the malware was simply stored in unused memory, rather than being in the BIOS or other boot ROM) is definitely a problem, but a deliberate attack is problematic.  The issue lies with hundreds of thousands of hobbyists (as well as some of the hackers) who poke and prod at everything.  True, the chance of discovering the attack is random, but so is the chance of keeping the attack undetected.  It isn’t something that an attacker could rely upon.

Yes, these days there are thousands of components, being manufactured by hundreds of vendors.  However, note various factors that need to be considered.

First of all, somebody has to make it.  Most major chips, like CPUs, are a combined effort.  Nobody would be able to make and manufacture a major chip all by themselves.  And, in these days of tight margins and using every available scrap of chip “real estate,” someone would be bound to notice a section of the chip labeled “this space intentionally left blank.”  The more people who are involved, the more likely someone is going to spill the beans, at the very least about an anomaly on the chip, whether or not they knew what it did.  (Once the word is out that there is an anomaly, the lifespan of that secret is probably about three weeks.)

Secondly, there is the issue of the payload.  What can you make it do?  Remember, we are talking components, here.  This means that, in order to make it do anything, you are generally going to have to rely on whatever else is in the device or system in which your chip has been embedded.  You cannot assume that you will have access to communications, memory, disk space, or pretty much anything else, unless you are on the CPU.  Even if you are on the CPU, you are going to be limited.  Do you know what you are?  Are you a computer? Smartphone?  iPod?  (If the last, you are out of luck, unless you want to try and drive the user slowly insane by refusing to play anything except Barry Manilow.)  If you are a computer, do you know what operating system you are running?  Do you know the format of any disk connected to you?  The more you have to know how to deal with, the more programming has to be built into you, and remember that real estate limitation.  Even if all you are going to do is shut down, you have to have access to communications, and you have to a) be able to watch all the traffic, and b) watch all the traffic, without degrading performance while doing so.  (OK, true, it could just be a timer.  That doesn’t allow the attacker a lot of control.)

Next, you have to get people to use your chips.  That means that your chips have to be as cheap as, or cheaper than, the competition.  And remember, you have to use up chip real estate in order to have your payload on the chip.  That means that, for every 1% of chip space you use up for your programming, you lose 1% of manufacturing capacity.  So you have to have deep pockets to fund this.  Your chip also has to be at least as capable as the competition.  It also has to be as reliable as the competition.  You have to test that the payload you’ve put in place does not adversely affect performance, until you tell it to.  And you have to test it in a variety of situations and applications.  All the while making sure nobody finds out your little secret.

Next, you have to trigger your attack.  The trigger can’t be something that could just happen randomly.  And remember, traffic on the Internet, particularly with people streaming videos out there, can be pretty random.  Also remember that there are hundreds of thousands of kids out there with nothing better to do than try to use their computers, smartphones, music players, radio controlled cars, and blenders in exactly the way they aren’t supposed to.  And several thousand who, as soon as something odd happens, start trying to figure out why.

Bad hardware definitely is a threat.  But the largest part of that threat is simply the fact that cheap manufacturers are taking shortcuts and building unreliable components.  If I was an attacker, I would definitely be able to find easier ways to mess up the infrastructure than by trying to create attack chips.

[1] Get it some night when you can borrow it, for free, from your local library DVD collection.  On an evening when you don’t want to think too much.  Or at all.  WARNING: contains jokes that six year olds, and most guys, find funny.

Caller-ID spoof and voicemail

It’s easy to spoof caller-ID with some VoIP systems.  There are a few Websites that specifically allow it.  It’s a little harder, but geekier, to spoof or overflow caller-ID with a simple Bell 212A modem: it’s transmitted with that tech between the first and second rings of the phone.  (Since most people have caller-ID these days, many telcos don’t play you the first ring.  Since we don’t have caller-ID, we often get accused of answering the phone before it rings.)  (Of course, the rings you hear on the calling side aren’t necessarily the rings heard on the other end, but …)

Apparently AT&T allows immediate access to voicemail on the basis of caller-ID.

Apparently, with Android phones, it’s also gotten even easier to spoof caller-ID.

REVIEW: “SSL and TLS: Theory and Practice”, Rolf Oppliger

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   “SSL and TLS: Theory and Practice”

The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

REVIEW: “Cloud Security and Privacy”, Tim Mather/Subra Kumaraswamy/Shahed Latif

BKCLSEPR.RVW   20091113

“Cloud Security and Privacy”, Tim Mather/Subra Kumaraswamy/Shahed Latif, 2009, 978-0-596-802769, U$34.99/C$43.99
%A   Tim Mather
%A   Subra Kumaraswamy
%A   Shahed Latif
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2009
%G   978-0-596-802769 0-596-802765
%I   O’Reilly & Associates, Inc.
%O   U$34.99/C$43.99 800-998-9938 707-829-0515
%O   Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   312 p.
%T   “Cloud Security and Privacy”

The preface tells how the authors met, and that they were interested in writing a book on clouds and security.  It provides no definition of cloud computing.  (It also emphasizes an interest in being “first to market” with a work on this topic.)

Chapter one is supposed to be an introduction.  It is very brief, and, yet again, doesn’t say what a cloud is.  (The authors aren’t very careful about building background information: the acronym SPI is widely used and important to the book, but is used before it is defined.  It stands for Saas/Paas/Iaas, or software-as-a-service, platform-as-a-service, and infrastructure-as-a-service.  More simply, this refers to applications, management/development utilities, and storage.)  A delineation of cloud computing is finally given in chapter two, stating that it is characterized by multitenancy, scalability, elasticity, pay-as-you-go options, and self-provisioning.  (As these aspects are expanded, it becomes clear that the scalability, elasticity, and self-provisioning characteristics the authors describe are essentially the same thing: the ability of the user or client to manage the increase or decrease in services used.)  The fact that the authors do not define the term “cloud” becomes important as the guide starts to examine security considerations.  Interoperability is listed as a benefit of the cloud, whereas one of the risks is identified as
vendor lock-in: these two factors are inherently mutually exclusive.

Chapter three talks about infrastructure security, but the advice seems to reduce to a recommendation to review the security of the individual components, including Saas, Paas, and network elements, which seems to ignore the emergent risks arising from any complex environment.  Encryption is said to be only a small part of data security in storage, as addressed in chapter four, but most of the material discusses encryption.  The deliberation on cryptography is superficial: the authors have managed to include the very recent research on homomorphic encryption, and note that the field will advance rapidly, but do not mention that homomorphic encryption is only useful for a very specific subset of data representations.  The identity management problem is outlined in chapter five, and protocols for managing new systems are reviewed, but the issue of integrating these protocols with existing systems is not.  “Security management in the Cloud,” as examined in chapter six, is a melange of general security management and operations management, with responsibility flipping back and forth between the customer and the provider.  Chapter seven provides a very good overview of privacy, but with almost no relation to the cloud as such.  Audit and compliance standards are described in chapter eight: only one is directed at the cloud.  Various cloud service providers (CSP) are listed in chapter
nine.  The terse description of security-as-a-service (confusingly also listed as Saas), in chapter ten, is almost entirely restricted to spam and Web filtering.  The impact of the use of cloud technology is dealt with in chapter eleven.  It lists the pros and cons, but again,
some of the points are presented without noting that they are mutually exclusive.  Chapter twelve finishes off the book with a precis of the foregoing chapters.

The authors do raise a wide variety of the security problems and concerns related to cloud computing.  However, since these are the same issues that need to be examined in any information security scenario it is hard to say that any cloud-specific topics are addressed.  Stripped of excessive verbiage, the advice seems to reduce to a) know what you want, b) don’t make assumptions about what the provider provides, and c) audit the provider.

copyright Robert M. Slade, 2009    BKCLSEPR.RVW   20091113