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.

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.)

Well, multiple scanners say I have no malware, no spyware, and no rootkits.

http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+ says I’m clean except for Spamhaus.

Spamhaus shows that http://www.spamhaus.org/query/bl?ip=70.79.166.169 I’m clean and it’s Shaw that’s dirty.

Shaw’s support is as inane as ever:

GoToAssist (11:43:33):
Your representative has arrived.

Stephen – 6685 (11:43:37):
Thank you for choosing Shaw Internet Chat Support, my name is Steve.  I will be happy to help you today.Before continuing, would you please confirm your home telephone number and address so that I can bring up your account information?

[If you don't mind, I've elided this, but it's the only change I've made - rms]

Stephen – 6685 (11:44:57):
Thank you, one moment please
Stephen – 6685 (11:48:07):
from what we see on the notes, it looks like your email is being blocked to due a poor reputation which means its being blocked by spam protection companies,  im just looking into this a little further for you.

Rob Slade (11:49:16):
Do you have any idea of what that means?  When I talked to “Rowell” yesteerday, he did not know anything about anti-spam technology, and just kept handing me bafflegab.  If you do not have any knowledge in thsi area, please hand me to someone who does.
Rob Slade (11:49:46):
I should let you know that I *do* know what I’m talking about: look up “Robert Slade” on Wikipedia.

Stephen – 6685 (11:49:48):
your being blocked by spamhaus
Stephen – 6685 (11:50:02):

http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+

Rob Slade (11:50:18):
I’ve written two books on viruses and malware, the first book on software forensics, and a dictionary of information security.
Rob Slade (11:50:38):
I do know what spam is, and I am well aware of antipsam technology.
Rob Slade (11:51:08):
Per looking at senderbase yesterday, my specific IP address has nothing on it.  Just Shaw’s domain range.

Stephen – 6685 (11:52:03):
you would need to go here   http://www.spamhaus.org/lookup.lasso   type in your ip address to lookup, then  click the document it shows under the listed in red, and follow the steps to get it removed from spamhaus

Rob Slade (11:52:29):

http://www.spamhaus.org/query/bl?ip=70.79.166.169

Rob Slade (11:53:04):
See that it is only listed in the PBL, and if you look up the detail on that you will see that it is only the Shaw /22 range, and not my address.
Rob Slade (11:53:49):
Going back to your original list, you will see that it is *only* listed on Spamhaus (and therefore only on the PBL), and that *all* the other sites give me a clean bill of health.
Rob Slade (11:54:19):
In addition, why did I get absolutely no warning or notice from Shaw, just had my ability to send cut off without warning?

Stephen – 6685 (11:54:27):
its not blocked by us
Stephen – 6685 (11:54:31):
thats why we couldnt give warning
Stephen – 6685 (11:54:37):
its blocked by spamhaus

Rob Slade (11:54:49):
It is your SMTP server that refuses the connectionh.
Rob Slade (11:55:00):
You can’t blame Spamhaus.

Stephen – 6685 (11:55:14):
http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+   please review this,  it will show you based on a search of your ip address, its listed by spamhaus-zen….

Rob Slade (11:55:52):
That is the same list as before.

Stephen – 6685 (11:56:19):
yes it is

Rob Slade (11:56:36):
As I told you, it gives me a clean bill of health, except for Spamhaus, and Spamhaus only lists the Shaw /22 range in the PBL, not my IP address specifically.

Stephen – 6685 (11:56:37):
if you look at the top.. spamhaus-zen  to the right of that it shows as listed  which means its blocked by them
Stephen – 6685 (11:57:00):
its still being listed by them, otherwise it would come up saying OK  next to spamhaus
Stephen – 6685 (11:57:16):
if you login to webmail  and try sending an email out from there, it will work because its not associated with your computer
Stephen – 6685 (11:57:30):
its not working on your computer because your ip  address is blocked by spamhaus

Rob Slade (11:57:44):
Yes, and if you look at the detail, you will see that I am *not* lsited in the SBL, *not* listed in the CBL, and *only* listed in the PBL, and if you look at the detail for *that* you will see that it is *Shaw* that violates, not me.
Rob Slade (11:58:37):
Here. chew on these: http://is.gd/VbjOIh http://is.gd/ogefIX

Stephen – 6685 (11:59:31):
im not sure what i am suppose to be seeing in those links..   Error establishing a database connection
Stephen – 6685 (12:00:07):
http://www.spamhaus.org/pbl/query/PBL164253  from there, you will need to follow the steps from clicking on remove an ip from pbl

Rob Slade (12:01:20):
In the meantime, I will be writing up more blog posts on how Shaw has inconsitent spam filtering, does not say what kind of spam filtering it does do, has a weird relationship with the blacklisting outfits.
Rob Slade (12:02:09):
Obviously you have not read the page you sent me.  This is the procedure only if you are running an email server (MTA) yourself.  I don’t.  You guys do.

Stephen – 6685 (12:05:15):
yes, from the report, its showing that its being blocked due to not using smpt authentication, that gets addressed from our side, where we communicate with spamhaus to get that resolved, however also by having you follow the link from the remove my ip address can usaully help get it resolved quicker.
Stephen – 6685 (12:06:12):
it is blocked by spamhaus, not us, which is something that will get looked into, if it was just being blocked by us, we could easily resolve it for you, however because its being blocked by a 3rd party, it will take some time, in the meantime you can use webmail to send and receive emails

Rob Slade (12:06:19):
How so?  I don’t run an SMTP server, so I can’t give them full info in filling out that form.
Rob Slade (12:07:06):
Besides, it’s not a static address.
Rob Slade (12:07:45):
Obviously you do not know what you are talkign about.  Are you going to put me through to someone who does?

Stephen – 6685 (12:08:08):
yes i do know what i am talking about Rob

Rob Slade (12:08:45):
Then how come you are asking em to fill out a form when the instructions specifically state not to do it unless this is a static IP address and I am running my own mail server?
Rob Slade (12:09:36):
http://www.spamhaus.org/pbl/removal/ “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”

Stephen – 6685 (12:09:37):
i am just looking to see what more we can do on this right now, i will be a couple minutes.

As noted, Shaw is not very helpful with spam.  I’ve been getting spam from Marlin Travel, and from a band of people selling recuriting seminars, for a number of years.  I have been reporting this spam (to Shaw, and their supposedly automated spam filters) on at least a weekly basis for years.  Occasionally they deign to mark one of the messages as spam, but not on anything like a consistent basis.

Spam filtering is not transparent.  You can turn it on, or off.  You can have the spam go to the bit bucket, or get flagged.  There are no other options, and you have no information on how it works (or doesn’t).  (Heck, Vancouver Community Net [formerly Free-Net] does better than that.)

On my non-support call with Shaw, the agent did correctly identify the IP address I am (currently) using.  I have no idea when last it was switched.  Looking it up on senderbase is not supremely informative: there doesn’t seem to be any information on the address itself, other than the fact that it’s not in the SpamHaus Block List (SBL) or the XBL.  It is 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.

Meantime I have confirmed that, as I already knew, there is nothing malware or spam related on my machine.  Nothing that MSE detects.  Nothing that Vipre detects.  Nothing that Spybot detects.  At the moment I’m running the Sophos rootkit detector, and F-Secure’s Blacklight.  They haven’t found anything either.  I am, of course, morally certain that Shaw was lying to me about the possibility, but, unlike them, I’m not arrogant enough not to check.  I was right: they are idiots.  And, with their non-support, have cost me a lot of valuable time checking a clean machine.  (Plus not providing the Internet service I’m paying for.)

BKEXTDET.RVW   20101023

“Extrusion Detection”, Richard Bejtlich, 2006, 0-321-34996-2,
U$49.99/C$69.99
%A   Richard Bejtlich www.taosecurity.com taosecurity.blogspot.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-34996-2
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/0321349962/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321349962/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321349962/robsladesin03-20
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   385 p.
%T   “Extrusion Detection:Security Monitoring for Internal Intrusions”

According to the preface, this book explains the use of extrusion detection (related to egress scanning), to detect intruders who are using client-side attacks to enter or work within your network.   The audience is intended to be architects, engineers, analysts, operators and managers with an intermediate to advanced knowledge of network security.  Background for readers should include knowledge of scripting, network attack tools and controls, basic system administration, TCP/IP, as well as management and policy.  (It should also be understood that those who will get the most out of the text should know not only the concepts of TCP/IP, but advanced level details of packet and log structures.)  Bejtlich notes that he is not explicitly addressing malware or phishing, and provides references for those areas.  (It appears that the work is not directed at information which might detect insider attacks.)

Part one is about detecting and controlling intrusions.  Chapter one reviews network security monitoring, with a basic introduction to security (brief but clear), and then gives an overview of monitoring and listing of some tools.  Defensible network architecture, in chapter two, provides lucid explanations of the basics, but the later sections delve deeply into packets, scripts and configurations.  Managers will understand the fundmental points being made, but pages of the material will be impenetrable unless you have serious hands-on experience with traffic analysis.  Extrusion detection itself is illustrated with intelligible concepts and examples (and a useful survey of the literature) in chapter three.   Chapter four examines both hardware and software instruments for viewing enterprise network traffic.  Useful but limited instances of layer three network access controls are reviewed in chapter five.

Part two addresses network security operations.  Chapter six delves into traffic threat assessment, and, oddly, at this point explains the details of logs, packets, and sessions clearly and in more detail.   A decent outline of the advance planning and basic concepts necessary for network incident response is detailed in chapter seven (although the material is generic and has limited relation to the rest of the content of the book).  Network forensics gets an excellent overview in chapter eight: not just technical points, but stressing the importance of documentation and transparent procedures.

Part three turns to internal intrusions.  Chapter nine is a case study of a traffic threat assessment.  It is, somewhat of necessity, dependent upon detailed examination of logs, but the material demands an advanced background in packet analysis.  The (somewhat outdated) use of IRC channels in botnet command and control is reviewed in chapter ten.

Bejtlich’s prose is clear, informative, and even has touches of humour.  The content is well-organized.  (There is a tendency to use idiosyncratic acronyms, sometimes before they’ve been expanded or defined.)  This work is demanding, particularly for those still at the intermediate level, but does examine an area of security which does not get sufficient attention.

copyright, Robert M. Slade   2010     BKEXTDET.RVW   20101023

BKCYWRFR.RVW   20101204

“Inside Cyber Warfare”, Jeffrey Carr, 2010, 978-0-596-80215-8,
U$39.99/C$49.99
%A   Jeffrey Carr greylogic.us
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2010
%G   978-0-596-80215-8 0-596-80215-3
%I   O’Reilly & Associates, Inc.
%O   U$39.99/C$49.99 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596802153/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596802153/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596802153/robsladesin03-20
%O   Audience n Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   212 p.
%T   “Inside Cyber Warfare: Mapping the Cyber Underworld”

The preface states that this text is an attempt to cover the very broad topic of cyber warfare with enough depth to be interesting without being technically challenging for the reader.

Chapter one provides examples of cyber attacks (mostly DDoS [Distributed Denial of Service]), and speculations about future offensives.  More detailed stories are given in chapter two, although the reason for the title of “Rise of the Non-State Hacker” isn’t really clear.  The legal status of cyber warfare, in chapter three, deals primarily with disagreements about military treaties.  A guest chapter (four) gives a solid argument for the use of “active defence” (striking back at an attacker) in cyber attacks perceived to be acts of war, based on international law in regard to warfare.  The author of the book is the founder of Project Grey Goose, and chapter five talks briefly about some of the events PGG investigated, using them to illustrate aspects of the intelligence component of cyber warfare (and noting some policy weaknesses, such as the difficulties of obtaining the services of US citizens of foreign birth).  The social Web is examined in chapter six, noting relative usage in Russia, China, and the middle east, along with use and misuse by military personnel.  (The Croll social engineering attack, and Russian scripted attack tools, are also detailed.)  Ownership links, and domain registrations, are examined in chapter seven, although in a restricted scope.  Some structures of systems supporting organized crime online are noted in chapter eight.  Chapter nine provides a limited look at the sources of information used to determine who might be behind an attack.  A grab bag of aspects of malware and social networks is compiled to form chapter ten.  Chapter eleven lists position papers on the use of cyber warfare from various military services.  Chapter twelve is another guest article, looking at options for early warning systems to detect a cyber attack.  A host of guest opinions on cyber warfare are presented in chapter thirteen.

Carr is obviously, and probably legitimately, concerned that he not disclose information of a sensitive nature that is detrimental to the operations of the people with whom he works.  (Somewhat ironically, I reviewed this work while the Wikileaks furor over diplomatic cables was being discussed.)  However, he appears to have gone too far.  The result is uninteresting for anyone who has any background in cybercrime or related areas.  Those who have little to no exposure to security discussions on this scale may find it surprising, but professionals will have little to learn, here.

copyright, Robert M. Slade   2010     BKCYWRFR.RVW   20101204

Well, I don’t know if this is a continuation in the “new computers” series, or just rehashing an old problem.

I’ve noted before the problem of the complexity of trying to establish an ad-hoc network under Windows.  And, I’m trying various things with the new Mac.  So, in a situation, right now, where I have one network cable, and two computers downstairs, I decided to see what an ad hoc network was like with a Mac.

I remembered to do the bridging thing on Windows, and I’ve set up an ad hoc network with a pre-shared key.  (At least, I think I have.  That seemed to be the way it worked, and the Mac connected with a password, but, on the Windows machine, when I go back and look at it, it says it’s open.)  The Mac wouldn’t show the network when I looked at the list, but, when I gave it the name and password it seemed to connect just fine.

I got a Web site correctly on the Mac.  Then I went to connect to the Windows machines as servers, and that worked out fine.  Then I went to do some work on the Web, and … nothing.  The Mac wasn’t able to get onto the Internet.  I was still connected to the Windows servers, but couldn’t get a Web page.

And, then, suddenly, I could, again.  And then I couldn’t.  (At the moment, I can’t.)  (Sorry, started working again just before I finished this entry.)
I’ll have to give it a shot with the Mac connected to the cable, and see if I can set up an ad hoc wireless connection that the Windows netbook can use, but, at the moment, Mac networking is not working any better than Windows in the ad hoc environment.

Roll on PopulistNet.

Reports are saying cell phones and Internet connections are off in egypt at the moment. Can a country really shut off its Internet connection?

China, who has placed restrictions on its Internet infrastructure from day 1 (meaning, the whole infrastructure for connecting to the Internet was built with government control in mind) and that develops a lot of its own networking equipment, is unable to really block users. When I’m in China, twitter and facebook are blocked in the hotel and in the office, but not on the blackberry. Most anonymizers work, and some twitter-over-instant messenger bots work as well. Most of the time, I can find the new list of working anonymizers on google, while I’m there – so there’s no special preparation involved. On my last visit I was introduced to a free VPN service that enables unrestricted access to facebook, twitter and other blocked sites, that seems to be quite popular in the country.

Egypt is not as big and certainly not as advanced as China, but is fairly big. As anyone who worked for a large company knows – it’s difficult if not impossible to track all incoming and outgoing connections. We know the DNS servers are refusing to resolve .eg domains – but what if we go into the inner-works. Are some of the IP’s inside Egypt reachable?

One glaring example is the Egyptian stock exchange. Its IP rotates, but at least some connections point to  217.139.183.2, which belongs to the ISP “the Noor group”, in Cairo. Other times it points to 41.222.175.2 that belongs to “Misr Information Services and Trading” in down-town Cairo. Both are clearly reachable and pingable; is every router on the way configured to route communication only to those IPs? Are there other routers, IP’s or servers that are still open for communication? I would imagine that some emergency lines run on IP-based infrastructure that must be kept on; some devices – military ones perhaps – might rely on IP infrastructure. Dial-ups might still exist. Speaking of which: can one dial from Egypt into a modem in Germany?
Also, one has to wonder about internal communication. Blocking the country’s gateways is one thing; but blocking all internal communication is extremely hard to do. If internal communication is available, is there a way to piggyback into those few holes in the dam to get external communication? Taking the egyptse.com example: if the perimeter routers only allow communication to/from the Noor network, can I route my connection through them?

We all know the Internet was designed to be resilient; and forty years after its initial deployment, it’s proving to be very hard to kill, even by those who believe they have their hand on the cut-off switch.

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.

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.

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.

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?

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: http://www.imdb.com/title/tt0436339/  [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.

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.

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%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 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%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

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 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596802765/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596802765/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596802765/robsladesin03-20
%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

So I’ve been sitting on an Apple vulnerability for over a month now, and I’m really starting to realise that maybe just sending the details to the Full-Disclosure mailing list and Exploit-DB.com is the right way to go about disclosing vulnerabilities and exploits.

I initially contacted ZDI to see if they would be at all interested in buying the exploit off of me, as I spent a lot of time researching and finding this one, and I’d like to get something for my efforts. I am a firm believer in the No More Free Bugs movement, I understand and appreciate what ZDI are doing, but the fact that it took them just under a month to get back to me, is really not good enough to be very honest. If they don’t have the researchers, then advertise worldwide, instead of just US only. I know I for one, would be happy validating bugs all day, and this is the the type of work that can be remotely.
Yesterday I also submitted the same information to iDefense Labs Vulnerability Contributor Program (VCP), who claim to get back to me within 48 hours, so we’ll see how that goes. I will update this post as and I when I know more.

I also took the off chance of mailing Apple directly, and asking if they offer any rewards for vulnerabilities that have been found, and if so what they would be. I don’t have high hopes on Apple offering anything, but to be honest, I would prefer to  disclose this one directly to Apple. They however  have paid staff to do this work on a full time basis on all their products, so why aren’t they doing it properly, and I feel that anyone else finding bugs for them, should be compensated appropriately. However, I e-mailed them yesterday and recieved an automated response, so we see how long it takes them to respond to me as well.

This may end up being a rather long post, but let’s see. I’m also expecting to see quite a few interesting comments on this post as well, so come on people.

UPDATE 30/06/2010:

Received a response from iDefense last night,and a request for more info. So just over 24 hour response time, which is brilliant, I’m really impressed so far.

Recieved a response from Apple, and if I would like any reward (aside from credit for the find), then I was informed that I should go through ZDI or iDefense.